On Thu, Apr 08, 2010 at 08:48:42PM +0200, Johannes Weiner wrote:
> On Thu, Apr 08, 2010 at 07:58:47PM +0200, Andrea Arcangeli wrote:
> > On Thu, Apr 08, 2010 at 07:56:04PM +0200, Johannes Weiner wrote:
> > > 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.
> >
> > The problem here are random compound pages that aren't owned by the
> > transparent hugepage subsystem. If we can't identify those, it's
> > unsafe to call compound_order (like it's unsafe to call page_order for
> > pagebuddy pages).
>
> But transparent huge pages are the only compound pages on the LRU, so
> we should be able to identify them.
>
> The lru_lock excludes isolation, splitting and collapsing, so I think
> this is safe:
>
> if (PageLRU() && PageTransCompound()) {
> low_pfn += (1 << compound_order()) - 1
> continue
> }
>
> if (__isolate_lru_page())
> continue
>
> ...
I don't see anything wrong with this. You're right lru_lock excludes
isolation, splitting and collapsing (collapsing if it's pagelru it
means it already happened).
Thanks for thinking this optimization in detail. I guess retaining the
other optimization will be harder. It depends how costly it is to take
the zone->lock, the main annoyance is that we can only do that if we
release the lru_lock first or we get lock inversion deadlocks. So it
costs 4 locked ops to skip max 1024 pages (but in average it'll be
much less than 1024 pages, more like 128 [no math just random guess]
when there's quite some ram free).
--
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>