Messages in this thread | | | Subject | Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller) | From | Rohit Seth <> | Date | Tue, 08 Aug 2006 10:34:21 -0700 |
| |
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
- 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/
| |