[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 08 Aug 2006 10:34:21 -0700
From: Rohit Seth <rohitseth@...gle.com>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Martin Bligh <mbligh@...igh.org>,
Dave Hansen <haveblue@...ibm.com>, Kirill Korotaev <dev@...ru>,
vatsa@...ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
Andrew Morton <akpm@...l.org>, mingo@...e.hu, sam@...ain.net,
linux-kernel@...r.kernel.org, dev@...nvz.org, efault@....de,
balbir@...ibm.com, sekharan@...ibm.com, nagar@...son.ibm.com,
pj@....com, Andrey Savochkin <saw@...ru>
Subject: Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going
forward with Resource Management - A cpu controller)
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists