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

[Matthew Helsley <matthltc@us.ibm.com>]

On Fri, 2005-07-22 at 20:23 -0400, Mark Hahn wrote:
> > > 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!

OK, so if it provides a path towards unifying these, what should happen
to the old interfaces when they conflict with those offered by CKRM?

For instance, I'm considering how a per-class (re)nice setting would
work. What should happen when the user (re)nices a process to a
different value than the nice of the process' class? Should CKRM:

a) disable the old interface by
	i) removing it
	ii) return an error when CKRM is active
	iii) return an error when CKRM has specified a nice value for the
process via membership in a class
	iv) return an error when the (re)nice value is inconsistent with the
nice value assigned to the class

b) trust the user, ignore the class nice value, and allow the new nice
value

	I'd be tempted to do a.iv but it would require some modifications to a
system call. b probably wouldn't require any modifications to non-CKRM
files/dirs. 

	This sort of question would probably come up for any other CKRM
"embraced-and-extended" tunables. Should they use the answer to this
one, or would it go on a case-by-case basis?

Thanks,
	-Matt Helsley

-
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/