On Tue, 29 Apr 2008, Andrea Arcangeli wrote: > Frankly I've absolutely no idea why rcu is needed in all rmap code > when walking the page->mapping. Definitely the PG_locked is taken so > there's no way page->mapping could possibly go away under the rmap > code, hence the anon_vma can't go away as it's queued in the vma, and > the vma has to go away before the page is zapped out of the pte.
zap_pte_range can race with the rmap code and it does not take the page lock. The page may not go away since a refcount was taken but the mapping can go away. Without RCU you have no guarantee that the anon_vma is existing when you take the lock. How long were you away from VM development? > Now the double atomic op may not be horrible when not contented, as it > works on the same cacheline but with cacheline bouncing with > contention it sounds doubly horrible than a single cacheline bounce > and I don't see the point of it as you can't use rcu anyways, so you > can't possibly take advantage of whatever microoptimization done over > the original locking. Cachelines are acquired for exclusive use for a mininum duration. Multiple atomic operations can be performed after a cacheline becomes exclusive without danger of bouncing. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
