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

["Magnus Damm" <magnus.damm@gmail.com>]

On 09 Aug 2006 06:33:54 +0200, Andi Kleen <ak@suse.de> wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> writes:
> >
> > - 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.
>
> This would need to be done at runtime though, otherwise it's useless
> for distributions and other people who want single kernel binary images.
>
> Probably would need a second parallel table, but for that you would
> need to know at boot already if you plan to use them or not. Ugly.

I've been thinking a bit about replacing the mapping and index members
in struct page with a single pointer that point into a cluster data
type. The cluster data type is aligned to a power of two and contains
a header that is shared between all pages within the cluster. The
header contains a base index and mapping. The rest of the cluster is
an array of pfn:s that point back to the actual page.

The cluster can be seen as a leaf node in the inode radix tree.
Contiguous pages in inode space are kept together in the cluster - not
physically contiguous pages. The cluster pointer in struct page is
used together with alignment to determine the address of the cluster
header and the real index (alignment + base index).

Anyway, what has all this to do with memory resource management? It
should be possible to add a per-cluster container pointer in the
header. This way the per-page overhead is fairly small - all depending
on the cluster size of course.

/ magnus
-
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/