Re: [ckrm-tech] Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

Jesse Barnes
2005-02-11T17:14:03Z

On Thursday, February 10, 2005 6:46 pm, Chandra Seetharaman wrote:
> On Wed, Feb 09, 2005 at 09:59:28AM -0800, Chandra Seetharaman wrote:
> > On Tue, Feb 08, 2005 at 12:42:34PM -0800, Paul Jackson wrote:
>
> --stuff deleted---
>
> > memset_controller would be similar to this, before pitching it I will
> > talk with Matt about why he thought that there is a problem.
>
> Talked to Matt Dobson and explained him the CKRM architecture and how
> cpuset/memset can be implemented as a ckrm controller. He is now convinced
> that there is no problem in making memset also a ckrm controller.
>
> As explained in the earlier mail, memset also can be implemented in the
> same way as cpuset.

Arg! Look, cpusets is *done* (i.e. it works well) and relatively simple and
easy to use. It's also been in -mm for quite some time. It also solves the
problem of being able to deal with large jobs on large systems rather
elegantly. Why oppose its inclusion upstream?

CKRM seems nice, but why is it not in -mm? I've heard it talked about a lot,
but it usually comes up as a response to some other, simpler project, in the
vein of "ckrm can do this, so your project is not needed" and needless to say
that's a bit frustrating. I'm not saying that ckrm isn't useful--indeed it
seems like an idea with a lot of utility (I liked Rik's ideas for using it to
manage desktop boxes and multiuser systems as a sort of per-process rlimits
on steroids), but using it for system partitioning or systemwide accounting
seems a bit foolish to me...

Jesse