Re: [RFC] Making compound pages mandatory

[David Howells <dhowells@redhat.com>]

> > Do you have any objection to compound pages being made mandatory, even
> > without HUGETLB support?
> 
> I haven't really looked into it, so I cannot make an informed decision.  
> How big is the overhead? And what's the _point_, since we don't seem to 
> need them normally, but the code is there for people who _do_ need them? 

The reason they might be useful under uClinux is that access_process_vm()
mucks around with pages in the middle of a high-order allocation.

Technically, with what was integrated to support uClinux and with the patch I
added, it's not actually necessary to use compound pages, I think, if only
because access_process_vm() provides some protections against munmap() and
exit().

However, that doesn't mean there isn't something I and the uClinux community
haven't noticed, or that situations won't arise in the future where the
current scheme is going to cause the kernel to explode.

> I don't generally like two paths, but quite frankly, I consider the
> non-compound case the regular case right now. How expensive does the
> compound pages end up being? Is it just one more pointer chase on every
> get_page/put_page, or what?

No, it's not. In put_page() it's _always_ going to be at least one more
pointer chase, and sometimes it's going to be two more; though the dcache may
offset this. put_page() refers not only to data in the first real page of a
compound page, but the second real page too.

Furthermore, put_page() becomes out of line. This means you've got register
clobberage and the mechanisms of function calls to deal with. Also you've got
more conditional instructions. I would propose also that the condition
checking for PG_compound be marked unlikely().

> Does anybody have numbers for before/after that are otherwise comparable?

I don't. However, the people hassling me about it might (hch for one).

David