Re: [Lse-tech] Hair brained scheme for grouping CpuMemSets

[Paul J. <pj...@en...>]

Ah - I realize a further confusion in my reading
of Michael's response to my hare brained proposal last week:

Michael, responding to Paul:
> > Proposed Solutions:
> >
> >  1) I think that any adequate solution to (1):
> >
> >      1a) must be hierarchical (groups and subgroups)
>                                                       
> Why?
>     
> >      1b) must be inherited (across fork and vm area creation),
>                                                                 
> No, but it must be possible to request inheritance (e.g., through
> the use of launch policies, or through specific system calls)


It must be the case that inheritance of processor and memory
restrictions can be _automatic_, without any explicit use by
the parent process of some launch policy or system call.

That is, it must be that some grandparent process can be fired
off to run on some particular node (or other specific set of
cpus and memory blocks), with the result that all the child and
grandchild processes spawned directly or indirectly from that
grandparent process remain constrained to run in no more (but
possibly less) than that original node (or specific set).  All
this with _no_ code in or awareness by any of these processes.

Like most constraints on the execution of a process in Unix (user
and group ids, ulimits, capabilities, nice value, controlling
tty, ...) the constraint as to which cpus it can schedule on,
and which nodes it can allocate from, and now the identify of
the allocation group to which it belongs for the purpose of bulk
migration, should be, and one would _expect_ to be, inherited.
In particular, the process allocation group is specified by the
cpumemmap, ahd hence inherited along with the rest of the map.

How in heavens else might you want the default setting of this,
if not by inheritance?

_Every_ task, _every_ vm area, has some cpumemmap and cpumemset.

There must be some default setting of these on each fork and
vm area creation, absent specific instructions to the contrary
from the creating process.  To my mind, the only obvious choice
of default value is by inheritance from the creator (in this
case, with the refinement that it's the CHILD value that is
inherited, as opposed to the parents CURRENT value).

I am rather puzzled that you would question this "Why?" or
doubt it "No".  That you did so suggests to me that you have
something quite different in mind, and that we are failing more
than we realize to communicate.

Or [wild guess alert here] is it only that you were objecting
to what you thought was an insistence from me that _only_
inheritance be available to determine the allocation group.
Of course, with explicit system calls (and adequate permission)
one needs to be able to set something other than what is
inherited.  Otherwise, everyone inherits the common value
from the init (pid == 1) process and the setting is useless.
Clearly I wouldn't advocate that.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj...@sg...> 1.650.933.1373