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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |