Messages in this thread |  | | | Date | Mon, 28 Apr 2008 18:28:06 -0700 (PDT) | | From | Christoph Lameter <> | | Subject | Re: [PATCH 01 of 12] Core of mmu notifiers |
| |
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.
|  |