Re: [ckrm-tech] Re: 2.6.13-rc3-mm1 (ckrm)

[Mark Hahn]

> > 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/