|From:||Andrew Morton <akpm-AT-osdl.org>|
|Subject:||Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul|
|Date:||Fri, 21 Apr 2006 19:13:40 -0700|
|Cc:||haveblue-AT-us.ibm.com, linux-kernel-AT-vger.kernel.org, ckrm-tech-AT-lists.sourceforge.net|
Chandra Seetharaman <email@example.com> wrote: > > > > > c) pointer to prototype code if poss > > Both the memory controllers are fully functional. We need to trim them > down. > > active/inactive list per class memory controller: > http://prdownloads.sourceforge.net/ckrm/mem_rc-f0.4-2615-... Oh my gosh. That converts memory reclaim from per-zone LRU to per-CKRM-class LRU. If configured. This is huge. It means that we have basically two quite different versions of memory reclaim to test and maintain. This is a problem. (I hope that's the before-we-added-comments version of the patch btw). > pzone based memory controller: > http://marc.theaimsgroup.com/?l=ckrm-tech&m=113867467... From a super-quick scan that looks saner. Is it effective? Is this the way you're planning on proceeding? This requirement is basically a glorified RLIMIT_RSS manager, isn't it? Just that it covers a group of mm's and not just the one mm? Do you attempt to manage just pagecache? So if class A tries to read 10GB from disk, does that get more aggressively reclaimed based on class A's resource limits? This all would have been more comfortable if done on top of the 2.4 kernel's virtual scanner. (btw, using the term "class" to identify a group of tasks isn't very comfortable - it's an instance, not a class...) Worried.
Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds