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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
