Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller)

[Rohit Seth <rohitseth@google.com>]

On Wed, 2006-08-09 at 00:19 +1000, Nick Piggin wrote:

> 
> What's the sucking semantics on exit? I haven't looked much at the
> existing memory controllers going around, but the implementation I
> imagine looks something like this (I think it is conceptually similar
> to the basic beancounters idea):
> 
> - anyone who allocates a page for anything gets charged for that page.
>    Except interrupt/softirq context. Could we ignore these for the moment?
> 

And what happens when processes belonging to different containers start
accessing the same page?
 
>    This does give you kernel (slab, pagetable, etc) allocations as well as
>    userspace. I don't like the idea of doing controllers for inode cache
>    and controllers for dentry cache, etc, etc, ad infinitum.
> 

IMO, we don't need to worry about the kernel internal data structures in
the first pass of container support.  I agree that something like dcache
can grow to consume a meaningful amount of memory in a system, but I
still think if we can have something more simple to start with that can
track user memory (both anon and pagecache) will be a good start.

> - each struct page has a backpointer to its billed container. At the mm
>    summit Linus said he didn't want back pointers, but I clarified with him
>    and he isn't against them if they are easily configured out when not using
>    memory controllers.
> 

I think adding a pointer to struct page brings additional cost without
that much of additional benefit.  Doing it at the address_space/anon_vma
level for page_cache is useful.

> - memory accounting containers are in a hierarchy. If you want to destroy a
>    container but it still has billed memory outstanding, that gets charged
>    back to the parent. The data structure itself obviously still needs to
>    stay around, to keep the backpointers from going stale... but that could
>    be as little as a word or two in size.
> 

Before we go and say that we need hierarchy of containers, we should
have a design of what a container should be containing.  AFAICS, flat
containers should be able to do the job.

But in general, if a container is getting aborted, then any residual
resources should also be aborted where ever make sense(may mean flushing
of any page_cache pages) or the operation should not be permitted. 

> The reason I like this way of accounting is that it can be done with a couple
> of hooks into page_alloc.c and an ifdef in mm.h, and that is the extent of
> the impact on core mm/ so I'd be against anything more intrusive unless this
> really doesn't work.
> 

hmm, probably the changes to core mm are not going to be that intrusive.
The catch will be what happens when you hit the limit of memory assigned
to a container.

-rohit