> On Thu, 7 Oct 2004, Paul Jackson wrote: > >> > I don't see what non-exclusive cpusets buys us. >> >> One can nest them, overlap them, and duplicate them ;) > > I would also add, if the decision comes to make 'real exclusive' cpusets, > my previous example, as a use for non-exclusive cpusets: > > we are running jobs that need to be 'mostly' isolated on some part of the > system, and run in a specific location. We use cpusets for that. But we > can't afford to dedicate a part of the system for administrative tasks > (daemons, init..). These tasks should not be put inside one of the > 'exclusive' cpusets, even temporary : they do not belong there. They > should just be allowed to steal a few cpu cycles from time to time : non > exclusive cpusets are the way to go.
That makes no sense to me whatsoever, I'm afraid. Why if they were allowed "to steal a few cycles" are they so fervently banned from being in there? You can keep them out of your userspace management part if you want. So we have the purely exclusive stuff, which needs kernel support in the form of sched_domains alterations. The rest of cpusets is just poking and prodding at cpus_allowed, the membind API, and the irq binding stuff. All of which you could do from userspace, without any further kernel support, right? Or am I missing something? M. ------------------------------------------------------- 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
