Re: [PATCH 56 of 67] Memory compaction core

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]