On Thu, Apr 08, 2010 at 07:14:58PM +0200, Andrea Arcangeli wrote:
> On Thu, Apr 08, 2010 at 07:09:48PM +0200, Andrea Arcangeli wrote:
> > + if (PageTransCompound(page)) {
> > + low_pfn += (1 << page_order(page)) - 1;
> > + continue;
> > + }
>
> Thinking again the low_pfn += I'll have to remove it even from the
> hugepage case, because this could be a compound page that doesn't
> belong to transparent hugepage support, so it could go away from under
> us and make the order-reading invalid despite we hold the lru_lock.
Compared to _splitting_ huge pages, it's already an improvement, even
without the clever skipping :-)
> Unless we mark the transparent hugepages with a special bit in the
> page->flags we can't retain this optimization.
>
> This would have been safe if we used compound_order and we knew it was
> owned by transparent hugepage support. Given how short we are in
> page->flags (I already had to remove the PG_buddy) it's unlikely we
> can mark it specially and retain this.
Humm, maybe the start pfn could be huge page aligned? That would make
it possible to check for PageTransHuge() and skip over compound_order()
pages. This way, we should never actually run into PG_tail pages.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>