On Wednesday 03 October 2007 17:25, Paul Jackson wrote: > Nick wrote: > > BTW. as far as the sched.c changes in your patch go, I much prefer > > the partition_sched_domains API: http://lkml.org/lkml/2006/10/19/85 > > > > The caller should manage everything itself, rather than > > partition_sched_domains doing half of the memory allocation. > > Please take a closer look at my partition_sched_domains() and its > interface to the scheduler. > > You should recognize this API, once you look at it. It simply passes > the full flat, hard partition, in its entirety. This is the > partitioning that you speak of, I believe. It's here; just not where > you expected it. > > The portion of the code that is in kernel/sched.c is just a little bit > of optimization. It avoids rebuilding all the sched domains and > reattaching every task to its sched domain; rather it determines which > sched domains were added or removed and just rebuilds them. > > Once you take a closer look, I hope you will agree that this new > interface between the cpuset and sched code provides a cleaner > separation.
I don't know what you think I said that is incorrect and requires me to look at again. I don't like your partition_sched_domains API because of the allocation thing. So I prefer the existing (or better, the simplified version in my patch referenced). The caller should determine which domain to rebuild and reattach. Simple. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
