Peter wrote:
> I prefer the proposition that CKRM be modified so that individual
> instances run within each cpuset to the proposition that CKRM take over
> everything.
I agree, pretty much. I wouldn't say that CKRM should run inside
_every_ cpuset. But some of them. And it's not so much that "CKRM is
running here or there", but that the CKRM, scheduler and allocator
decisions are made based on information relative to such a cpuset,
rather than being made mostly on the basis of system wide information
(only to be second guessed at the last stroke before affecting a
decision by a cpus or mems allowed mask prohibiting the planned action).
I would expect CKRM to want improved guarantees of exclusive and
non-overlapping control of all cpus, memory, tasks and affinity masks
within a cpuset it was managing. Smart schedulers that can handle
varying domains, and smart allocators, whether CKRM aware or not, might
also want such guarantees, and might also be able to treat such a cpuset
as a separate domain.
But I also expect CKRM, _even_ if cpusets are not configured on a
system, to be able to cope with tasks whose cpu affinity mask and memory
allocation zone lists have been constrained by sched_setaffinity, mbind
and set_mempolicy calls.
> In fact, I think that CKRM components that could be
> classified as "enabling technology" should be split out of CKRM as
> separate mechanisms and developed separately (possibly by the CKRM team)
> and that CKRM just be a client of these mechanisms.
Good idea. I see under the CKRM covers mechanisms to:
* monitor the rate of usage of such fungible kernel resources as
cpu cycles, page faults, and i/o transfers
* throttle the rate of usage of these resources, by inserting small
delays,
* classify threads by user class and
* track these usage rates per user class.
Good chance I'm missing something in this list, or miss-stating something.
But whatever the list, these mechanisms might better be separate,
generally usable mechanisms.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
