Re: [ckrm-tech] [RFC] [PATCH 00/12] CKRM after a major overhaul

Chandra Seetharaman
2006-04-22T19:32:05Z

On Fri, 2006-04-21 at 19:13 -0700, Andrew Morton wrote:
> 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.

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.