On Wed, 13 Feb 2002, Paul Jackson wrote:
> Michael Hohnbaum wrote:
> |> Martin Bligh had a couple of suggestions for how to deal with
> |> the cpu_t. I'll probably take his suggestion of using a cpu_t
> |> and defining that as a long. Then when a real cpu_t is defined
> |> it should be a trivial transition.
>
> There's more to compatibility than source compatibility at the
> point of the call. In particular, it essential that the nearby
> application code that manipulates the cpu_t be independent
> of the size of cpu_t. And it is also good if the binary API
> across the kernel boundary is stable, though in Linux this is
> not considered to be essential.
>
> This means to me that nothing in the published interface makes
> any mention of the size of cpu_t. Byte the bullet up front,
> with routines, such as the FD_SET et. al. routines in the select
> interface, or sigaddset et. al. routines in the POSIX sigsetops
> interface. Or, if you need sorted sets, not just unordered
> sets, then something like the (admittedly more cumbersome)
> cpumemsets interface for passing ordered sets of cpus and mems.
> Or have this simple binding work over abstractly bound cpu/mem
> numbers and forever be constrained to 32 or 64 (bits in a word)
> cpus and mems. But don't ask applications to write to one API,
> then change in anyway more than trivially cosmetic.
I've not yet found an approach to dealing with the cpu bitmask
that solves all of the concerns. For now, we are going to proceed
with using a long and living with a 32/64 bit limit. Using
abstract binding to map CPUs beyond that range sounds like a
good solution, although not perfect.
> |> > 6) You state that "Launch policies are not inherited" (with
> |> > emphasis on the 'not'). ...
> |>
> |> Your understanding is correct, and also spells out quite clearly
> |> why launch policies are not inherited.
>
> Ok - then this is a bug (er eh missing feature) in cpumemsets,
> because the *child* cpumemset (essentially the holder of the
> launch policy) is inherited. That is, both the *current* and
> *child* cpumemsets are initialized on fork from the parents
> *child* settings, and subsequent changes by the forked process
> do _not_ affect its already established *child* settings.
>
> So cpumemsets must support, at least as an option, the ability
> to support this non-inherited launch policy semantics, such
> that the *child* policy is not used unless something like a
> setlaunch() request activates it, and until then, the *current*
> policy applies to everything, both current process and any
> launched children.
>
> Question in this case: which policy, x4 or x5, would apply to
> process P3 in the following scenario:
>
> > 1. Process P1 (operating under policy x1) sets a launch policy x2
> > 2. Process P1 forks P2
> > 3. Process P2 modifies its own policy (rebinds) to policy x3
> > 4. Process P2 sets its launch policy to policy x4
> > 5. Process P2 again modifies its own policy, this time to x5
> > 6. Process P2 forks P3.
Since P2 has a launch policy in affect (x4), then this is the policy
that the new child process gets.
>
> ===
>
> The placeholder numamap argument still bothers me -- I don't
> understand it, don't know how to use it, and in general
> suspect that placeholder arguments are the cannon fodder of
> future reality.
>
For now, the numamap argument is just ignored. The easiest way to "use"
it is to pass in NULL. It is there so that abstract binding can be
added to the API. Abstract binding requires a data structure more
complex than a bit map. I would really like to say that the numamap
is a cpumemmap_t, but until I can resolve how to deal with nodes, am
reluctant to do so.
Michael Hohnbaum
hohnbaum@...
|