On Tue, 2004-10-05 at 19:39, Paul Jackson wrote: > Matthew wrote: > > > > I feel that the actual implementation, however, is taking > > a wrong approach, because it attempts to use the cpus_allowed mask to > > override the scheduler in the general case. cpus_allowed, in my > > estimation, is meant to be used as the exception, not the rule. > > I agree that big chunks of a large system that are marching to the beat > of two distinctly different drummers would better have their schedulers > organized along the domains that you describe, than by brute force abuse > of the cpus_allowed mask.
Wonderful news! :) > I look forward to your RFC, Matthew. Though not being a scheduler guru, > I will mostly have to rely on the textual commentary in order to > understand what it means. Wow, building a fan base already. I'll need all the cheerleaders I can get! ;) > Existing finer grain placement of CPUs (sched_setaffinity) and Memory > (mbind, set_mempolicy) already exists, and is required by parallel > threaded applications such as OpenMP and MPI are commonly used to > develop. Absolutely. I have no intention of removing or modifying those mechanisms. My only goal is to see that using them remains the exceptional case, and not the default behavior of most tasks. > The finer grain use of non-exclusive cpusets, in order to support > such workload managers as PBS and LSF in managing this finer grained > placement on a system (domain) wide basis should not be placing any > significantly further load on the schedulers or resource managers. > > The top level cpusets must provide additional isolation properties so > that separate scheduler and resource manager domains can work in > relative isolation. I've tried hard to speculate what these additional > isolation properties might be. I look forward to hearing from the CKRM > and scheduler folks on this. I agree that simple unconstrained (ab)use > of the cpus_allowed and mems_allowed masks, at that scale, places an > undo burden on the schedulers, allocators and resource managers. I'm really glad to hear that, Paul. That unconstrained (ab)use was my only real concern with the cpusets patches. I look forward to massaging our two approaches into something that will satisfy all interested parties. -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
