![]() | ||||||||||
Messages in this thread |
Paul Jackson wrote: > Max wrote: >> So far it seems that extending cpu_isolated_map >> is more natural way of propagating this notion to the rest of the kernel. >> Since it's very similar to the cpu_online_map concept and it's easy to integrated >> with the code that already uses it. > > If it were just realtime support, then I suspect I'd agree that > extending cpu_isolated_map makes more sense. > > But some people use realtime on systems that are also heavily > managed using cpusets. The two have to work together. I have > customers with systems running realtime on a few CPUs, at the > same time that they have a large batch scheduler (which is layered > on top of cpusets) managing jobs on a few hundred other CPUs. > Hence with the cpuset 'sched_load_balance' flag I think I've already > done what I think is one part of what your patches achieve by extending > the cpu_isolated_map. > > This is a common situation with "resource management" mechanisms such > as cpusets (and more recently cgroups and the subsystem modules it > supports.) They cut across existing core kernel code that manages such > key resources as CPUs and memory. As best we can, they have to work > with each other. Thanks for the info Paul. I'll definitely look into using this flag instead and reply with pros and cons (if any). Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-01-28 21:51 [from the cache] ©2003-2008 | ||||||||||