On Tue, 2005-09-27 at 01:37 -0700, Paul Jackson wrote: > You will need to encourage someone else, with scheduler expertise, > to review that portion of the patch. The kernel/sched.c file is > too hard for me; I stick to easier files such as kernel/cpuset.c. > > I continue to be quite suspicious that perhaps there should be a > tighter relation between your work and CKRM. For one thing, I suspect > that CKRM has a cpu controller that serves essentially the same purpose > as yours. If that is so, I cannot imagine that we would ever put both > cpu controllers in the kernel. They touch on code that is changing too > rapidly, and too critical for performance. > > My wild guess would be that the right answer would be to take the > CKRM cpu controller instead of yours, and connect it to cpusets in the > manner that you have done here. But I have no expertise in cpu > controllers, so am quite unfit to judge which one or the other, or > perhaps some combination of the two cpu controllers, is the best one. >
Last time I looked at the CKRM cpu controller code I found it was quite horrible, with a great deal of duplication and very intrusive large and complex. It could have come a long way since then, but this code looks much neater than the code I reviewed. I guess the question of the resource controller stuff is going to come up again sooner or later. I would hope to have just a single CPU resource controller (presumably based on cpusets), the simpler the better ;) Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
