Take the lock from interrupt context and it'll deadlock.
> That's not the case either though, see the in_interrupt() check
> in my tree in free_pages_ok, only normal context is allowed to play with
> pagecache. (async-io isn't in my tree)
Yes, I'm adding the same check to 2.5. It's anon pages as well
as pagecache pages. And unless we have a
BUG_ON(PageLRU(page) && in_interrupt())
in put_page_testzero() then I'm not sure how we can be sure that
aio is the only problem area.
> >
> > The removal of pages from the LRU is rather a mess. It's getting
> > better, and we can fix up some more of this if/when pagemap_lru_lock
> > becomes an interrupt-safe lock.
>
> that will allow irq to manage pagecahce but the fact it's not interrupt
> safe it's really a irq latency feature,
Not sure what you mean by this?
> the fact disabling irqs during
> the critical section decreases contention on the lock is kind of hack,
> that is true for all spinlocks out there, by that argument all spinlocks
> should be irq safe.
Sure. If the lock is heavily used, performance critical and you've
done the work to ensure that maximum hold time is small, it is
well worth doing. Plus we need it for free-from-interrupt-context,
and we may need it for performing LRU list motion within IO completion,
although that's looking a bit remote at present.
-
-
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/