![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-08-09 08:03 [from the cache] ©2003-2008 | |||||||||||||