I've put some more thought into this and I don't see any real problem with
the atomic_dec_and_lock strategy. The only efficiency drawback is the extra
locked cmpxchg on every page count dec, and that most likely tips the
efficiency advantage ever so slightly in favor of my current strategy.
Something else I like about the current strategy is the way the trylock
avoids contention - if shrink_cache is active it just leaves the page on the
lru for collection later. Sweeping up the orphans is efficient, since the
lru lock is batched by shrink_cache.
I think I may be even able to make this all work without holding the extra
count, but I'll treat that as a background project. The important thing is,
the page reaping cycle was never correct before, now it just might be.
I'm looking at your spinlock_irq now and thinking the _irq part could
possibly be avoided. Can you please remind me of the motivation for this -
was it originally intended to address the same race we've been working on
here?
I can see the advantage of being able to take the lru lock from interrupt
context, but we may be able to achieve the intended effect with a trylock.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/