Messages in this thread | | | Date | Fri, 21 Apr 2006 19:13:40 -0700 | From | Andrew Morton <> | Subject | Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul |
| |
Chandra Seetharaman <sekharan@us.ibm.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-v2.tz?download
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=113867467006531&w=2
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. - 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/
| |