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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
