[lkml]   [2005]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)
> > actually, let me also say that CKRM is on a continuum that includes 
> > current (global) /proc tuning for various subsystems, ulimits, and
> > at the other end, Xen/VMM's. it's conceivable that CKRM could wind up
> > being useful and fast enough to subsume the current global and per-proc
> > tunables. after all, there are MANY places where the kernel tries to
> > maintain some sort of context to allow it to tune/throttle/readahead
> > based on some process-linked context. "embracing and extending"
> > those could make CKRM attractive to people outside the mainframe market.
> Seems like an excellent suggestion to me! Yeah, it may be possible to
> maintain the context the kernel keeps on a per-class basis instead of
> globally or per-process.

right, but are the CKRM people ready to take this on? for instance,
I just grepped 'throttle' in kernel/mm and found a per-task RM in
page-writeback.c. it even has a vaguely class-oriented logic, since
it exempts RT tasks. if CKRM can become a way to make this stuff
cleaner and more effective (again, for normal tasks), then great.
but bolting on a big new different, intrusive mechanism that slows
down all normal jobs by 3% just so someone can run 10K mostly-idle
guests on a giant Power box, well, that's gross.

> The real question is what constitutes a useful
> "extension" :).

if CKRM is just extensions, I think it should be an external patch.
if it provides a path towards unifying the many disparate RM mechanisms
already in the kernel, great!

> I was thinking that per-class nice values might be a good place to
> start as well. One advantage of per-class as opposed to per-process nice
> is the class is less transient than the process since its lifetime is
> determined solely by the system administrator.

but the Linux RM needs to subsume traditional Unix process groups,
and inherited nice/schd class, and even CAP_ stuff. I think CKRM
could start to do this, since classes are very general.
but merely adding a new, incompatible feature is just Not A Good Idea.

regards, mark hahn.

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-07-23 02:26    [W:0.078 / U:32.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site