> > Yeah -- cpusets are hierarchical. And some of the use cases for
Yup. We've got a square peg and a round hole. An impedance mismatch.
That's the root cause of this entire wibbling session, in my view.
The essential role of cpusets, cgroups and much other such work of
recent, in my view, is pounding this square peg into that round hole.
In essence, it is fitting the hierarchical structure of the
organizations (corporations, universities and governments) who own big
systems to the flat, system-wide mandates needed to manage a given
computer system.
Well, such a change would be rather substantial and undesired,
if those terms help you more.
If I understand your approach to the kernel-to-user interface correctly
(sometimes I doubt I do) then your approach expected some user space code
or person or semi-intelligent equivalent to define a flat partition,
which will then be used to determine the sched domains.
In the batch scheduler case, running on a large shared system used
perhaps by several departments, no one entity can do that. One person,
perhaps the system admin, knows if they want to give complete control
of some big chunk of CPUs to a batch scheduler. The batch scheduler,
written by someone else far away and long ago, knows which jobs are
actively running on which subsets of the CPUs the batch scheduler is
using.
There is no single monolithic entity on such systems who knows all and
can dictate all details of a single, flat, system-wide partitioning.
The partitioning has to be sythesized from the combined requests of
several user space entities. That's ok -- this is bread and butter
work for cpusets.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
-
