> 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.
OK, makes sense. Thanks for that. > Of course, in our case, a valid argument is that 'exclusiveness' should > not be enforced by the kernel but rather by the job scheduler. Probably. > > But now I see that the discussion is going towards: > -fully exclusive cpusets, maybe even with no interrupts handling > -maybe only allow exclusive cpusets, since non-exclusive cpusets are > tricky wrt CKRM. Nope - personally I see us more headed for the exclusive cpusets, and handle the non-exclusive stuff via a more CKRM-style mechanism. Which I still think achieves what you need, though perhaps not in exactly the fashion you envisioned. 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
