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

From: Magnus Damm
Date: Wed Aug 09 2006 - 01:57:53 EST

On 09 Aug 2006 06:33:54 +0200, Andi Kleen <ak@xxxxxxx> wrote:
Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at