On Sat, Oct 30, 2010 at 3:16 AM, Michel Lespinasse <walken@xxxxxxxxxx> wrote:
> The following code at the bottom of try_to_unmap_one appears to be dead:
>
> out_mlock:
> pte_unmap_unlock(pte, ptl);
>
> /*
> * We need mmap_sem locking, Otherwise VM_LOCKED check makes
> * unstable result and race. Plus, We can't wait here because
> * we now hold anon_vma->lock or mapping->i_mmap_lock.
> * if trylock failed, the page remain in evictable lru and later
> * vmscan could retry to move the page to unevictable lru if the
> * page is actually mlocked.
> */
> if (down_read_trylock(&vma->vm_mm->mmap_sem)) {
> if (vma->vm_flags & VM_LOCKED) {
> mlock_vma_page(page);
> ret = SWAP_MLOCK;
> }
> up_read(&vma->vm_mm->mmap_sem);
> }
> return ret;
All right, not entirely dead - Documentation/vm/unevictable-lru.txt
actually explains this very well.
But still, the problem remains that lazy mlocking doesn't work while
mmap_sem is exclusively held by a long-running mlock().
> One approach I am considering would be to modify
> __mlock_vma_pages_range() and it call sites so the mmap sem is only
> read-owned while __mlock_vma_pages_range() runs. The mlock handling
> code in try_to_unmap_one() would then be able to acquire the
> mmap_sem() and help, as it is designed to do.
I'm still looking for any comments people might have about this :)
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href