[lkml]   [2005]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/3] CPUMETER: add cpumeter framework to the CPUSETS
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 ;)


SUSE Labs, Novell Inc.

Send instant messages to your online friends

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-27 11:25    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean