Messages in this thread | | | Date | Mon, 5 Dec 2005 09:03:13 -0800 (PST) | From | Christoph Lameter <> | Subject | Re: [RFC] Use compound pages for higher order slab allocations. |
| |
On Sat, 3 Dec 2005, Manfred Spraul wrote:
> Christoph Lameter wrote: > > > +static inline struct page *virt_to_compound_page(const void *addr) > > +{ > > + struct page * page = virt_to_page(addr); > > + > > + if (PageCompound(page)) > > + page = (struct page *)page_private(page); > > + > > > This would end up in every kmem_cache_free/kfree call. Is it really worth the > effort, are the high order allocation a problem?
The use of compound pages allows the handling of the higher order allocated page as one unit in a generic slab independent way. Currently struct page elements have a slab specific meaning and must be inspected in a slab specific way to figure out where the higher order page starts. Having compound pages allows a generic handling of higher order pages unifying f.e. hugepage handling with slab handling etc.
Not sure if this is worth it but it may make the handling of these pages easier for page migration, hotplug and bad memory relocation. Other endeavors that either scan struct page arrays or may start processing with any struct page also currently have to deal with the slab specific way of handling higher order pages.
> I'm against such a change without a clear proof that just using high order > allocations is not possible.
We are doing it right now so its definitely possible.
- 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/
| |