lkml.org 
[lkml]   [2006]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller)
    From
    Date
    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/

    \
     
     \ /
      Last update: 2006-08-08 19:39    [W:3.893 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site