Re: RFC: reviving mlock isolation dead code

[Michel Lespinasse <walken@google.com>]

On Sat, Oct 30, 2010 at 3:16 AM, Michel Lespinasse <walken@google.com> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>