On Thu, 10 Jan 2008, Matt Mackall wrote: > Well, I think we'd still have the same page size, in the sense that we'd > have a struct page for every hardware page and we'd still have hardware > page-sized pages in the page cache. We'd just change how we allocated > them. Right now we've got a stack that looks like:
We would not change the hardware page. Cannot do that. But we would have preferential threadment for 64k and 2M pages in the page allocator? > buddy / page allocator > SL*B allocator > kmalloc > > And we'd change that to: > > buddy allocator > SL*B allocator > page allocator / kmalloc > > So get_free_page() would still hand you back a hardware page, it would > just do it through SL*B. Hmm.... Not sure what effect this would have. We already have the pcp's that have a similar effect. > > It would decrease listlock effect drastically for SLUB. > > Not sure what you're referring to here. Allocations in 64k chunks means 16 times less basic allocation blocks to manage for the slab allocators. So the metadata to be maintained by the allocators is reduces by that factor. SLUB only needs to touch the list_lock (in some situations like a free to a non cpu slab) if a block becomes completely empty or is going from fully allocated to partially allocated. The larger the block size the more objects are in a block and the less of these actions that need a per node lock are needed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
