lkml.org 
[lkml]   [2005]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.13-rc3-mm1 (ckrm)


Paul Jackson wrote:

Sorry for the late response - I just saw this note.

> Shailabh wrote:
>
>>So if the current CPU controller
>> implementation is considered too intrusive/unacceptable, it can be
>>reworked or (and we certainly hope not) even rejected in perpetuity.
>
>
> It is certainly reasonable that you would hope such.
>
> But this hypothetical possibility concerns me a little. Where would
> that leave CKRM, if it was in the mainline kernel, but there was no CPU
> controller in the mainline kernel?

It would be unfortunate indeed since CPU is the first resource that
people want to try and control.

However, I feel the following are also true:

1. It is still better to have CKRM with the I/O, memory, network,
forkrate controllers than to have nothing just because the CPU
controller is unacceptable. Each controller is useful in its own right.
It may not be enough to justify the framework all by itself but together
with others (and the possibility of future controllers and per-class
metrics), it is sufficient.

2. A CPU controller which is acceptable can be developed. It may not
work as well because of the need to keep it simple and not affect the
non-CKRM user path, but it will be better than not having anything.
Years ago, people said a low-overhead SMP scheduler couldn't be written
and they were proved wrong. Currently Ingo is hard at work to make
acceptable-impact real time scheduling happen. So why should we rule out
the possibility of someone being able to develop a CKRM CPU controller
with acceptable impact ?

Basically, I'm pointing out that there is no reason to hold the
acceptance of the CKRM framework + other controller's hostage to its
current CPU controller implementation (or any one controller's
implementation for that matter).


> Wouldn't that be a rather serious
> problem for many users of CKRM if they wanted to work on mainline
> kernels?

Yes it would. And one could say that its one of the features of the
Linux kernel community that they would have to learn to accept. Just
like the embedded folks who were rooting for realtime enhancements to be
made mainstream for years now, like the RAS folks who have been making a
case for better dump/probe tools, and you, who's tried in the past to
get the community to accept PAGG/CSA :-)

But I don't think we need to be resigned to a CPU controller-less
existence quite yet. Using the examples given earlier, realtime is
being discussed seriously now and RAS features are getting acceptance.
So why should one rule out the possibility of an acceptable CPU
controller for CKRM being developed ?

We, the current developers of CKRM, hope our current design can be a
basis for the "one controller to rule them all" ! But if there are other
ways of doing it or people can point out whats wrong with the
implementation, it can be reworked or rewritten from scratch.

The important thing, as Andrew said, is to get real feedback about what
is unacceptable in the current implementation and any ideas on how it
can be done better. But lets start off with what has been put out there
in -mm rather than getting stuck on discussing something that hasn't
been even put out yet ?


--Shailabh



-
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: 2005-07-28 22:19    [W:0.256 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site