On Fri, 2006-04-21 at 19:13 -0700, Andrew Morton wrote:
> Chandra Seetharaman <[email protected]> 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.
Yes. We originally had an implementation that would use the existing
per-zone LRU, but the reclamation path was O(n), where n is the number
of classes. So, we moved towards a O(1) algorithm.
>
> This is huge. It means that we have basically two quite different versions
> of memory reclaim to test and maintain. This is a problem.
Understood, will work and come up with an acceptable memory controller.
>
> (I hope that's the before-we-added-comments version of the patch btw).
Yes, indeed :). As I told earlier this patch is not ready for lkml or -
mm yet.
>
> > 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?
>
Yes, it is effective, and the reclamation is O(1) too. It has couple of
problems by design, (1) doesn't handle shared pages and (2) doesn't
provide support for both min_shares and max_shares.
> 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?
Yes, that is the core object of ckrm, associate resources to a group of
tasks.
>
> 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?
Yes, it would get more aggressively reclaimed. But, if you have the I/O
controller also configured appropriately only class A will be affected.
>
> 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...)
We could go with "Resource Group" as Matt suggested.
>
>
Valerie, KUROSAWA, Please free to add any more details.
> Worried.
--
----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- [email protected] | .......you may get it.
----------------------------------------------------------------------
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
