lockless pagecache followups

Hi,

I'm going to submit my lockless pagecache patch to -mm. So I should clarify a few questions I didn't have time or thought capacity to answer in my OLS presentation when they were asked:

- The numbers in the presentation were with !CONFIG_PREEMPT kernels.

- I believe the speculative reference retry mechanism *could* use a seqlock rather than PG_nonewrefs + pagecache recheck. So that was a good question :) However, this doesn't fix the "all pages have an unstable refcount" problem.

Also, it means readers will contend cachelines with writers in different parts of the file, and does make a finer grained write side possibly more difficult in some parts. So I prefer the custom locking protocol.

- The flush_dcache_mmap_lock AFAIKS(?) is logically a different lock from the pagecache tree_lock. I guess it just uses tree_lock because it can. So that path should be sped up with the rwlock -> spinlock conversion, and reduced contention from find_get_page.

If there are any problems in this area, I'd like to know what they are.

- Comments have been improved.

- I still can't see how the lockless gang lookup could deadlock. If the radix-tree lookup finds 0 candidates, find_get_pages will return. The only time it retries is when the radix-tree lookup has found at least 1 page, and the first page found has been moved.

- One question I would have liked asked is "why not use RCU for freeing the pages", although maybe that's obvious ;) It would solve the unstable refcount, and the atomic_inc_not_zero problems, however I think RCU would be too much burden on the pagecache freeing side.

Thanks,
Nick

SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>