Messages in this thread | | | Date | Wed, 9 Aug 2006 15:00:01 +0900 | From | "Magnus Damm" <> | Subject | Re: memory resource accounting (was Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller) |
| |
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/
| |