On Tue, 2004-10-05 at 02:26, Simon Derr wrote: > I'd like to present you at this point what was the original decision for > having exclusive (called strict, at this point in history) and > non-exclusive cpusets. > > The idea was to have a system, and run all jobs on it through a batch > scheduler. Some jobs cared about performance, some didn't. > > The ones who cared about performance got an 'exclusive' cpuset, the ones > who didn't got a 'non exclusive' cpuset.
It sounds to me (and please correct me if I'm wrong) like 'non exclusive' cpusets are more like a convenient way to group tasks than any sort of performance or scheduling imperative. It would seem what we'd really want here is a task grouping functionality, more than a 'cpuset'. A cpuset seems a bit heavy handed if all we want to do group tasks for ease of administration. > There are still processes running outside the job cpusets (i.e in the root > cpuset), sshd, the batch scheduler. These tasks use a low amount of CPU, > so it is okay if they happen to run inside even 'exclusive' cpusets. For > us, 'exclusive' only means that no other CPU-hungry job is going to share > our CPU. If that's all 'exclusive' means then 'exclusive' is a poor choice of terminology. 'Exclusive' sounds like it would exclude all tasks it is possible to exclude from running there (ie: with the exception of certain necessary kernel threads). -Matt ------------------------------------------------------- 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
