On Saturday 31 August 2002 22:26, Andrew Morton wrote:
> Daniel Phillips wrote:
> >
> > Manfred suggested an approach to de-racing this race using
> > atomic_dec_and_lock, which needs to be compared to the current approach.
>
> Could simplify things, but not all architectures have an optimised
> version. So ia64, mips, parisc and s390 would end up taking
> the lru lock on every page_cache_release.
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/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:14 EST