• Andrew Morton's avatar
    [PATCH] rmap 8 unmap nonlinear · 108e3158
    Andrew Morton authored
    From: Hugh Dickins <hugh@veritas.com>
    
    The previous patch let the ptes of file pages be located via page
    ->mapping->i_mmap and i_mmap_shared lists of vmas; which works well unless
    the vma is VM_NONLINEAR - one in which sys_remap_file_pages has been used
    to place pages in unexpected places, to avoid an explosion of distinct
    unmergable vmas.  Such pages were effectively locked in memory.
    
    page_referenced_file is already skipping nonlinear vmas, they'd just waste
    its time, and age unfairly any pages in their proper positions.  Now extend
    try_to_unmap_file, to persuade it to swap from nonlinears.
    
    Ignoring the page requested, try to unmap cluster of 32 neighbouring ptes
    (in worst case all empty slots) in a nonlinear vma, then move on to the
    next vma; stopping when we've unmapped at least as many maps as the
    requested page had (vague guide of how hard to try), or have reached the
    end.  With large sparse nonlinear vmas, this could take a long time:
    inserted a cond_resched while no locks are held, unusual at this level but
    I think okay, shrink_list does so.
    
    Use vm_private_data a little like the old mm->swap_address, as a cursor
    recording how far we got, so we don't attack the same ptes next time around
    (earlier tried inserting an empty marker vma in the list, but that got
    messy).  How well this will work on real- life nonlinear vmas remains to be
    seen, but should work better than locking them all in memory, or swapping
    everything out all the time.
    
    Existing users of vm_private_data have either VM_RESERVED or VM_DONTEXPAND
    set, both of which are in the VM_SPECIAL category where we never try to
    merge vmas: so removed the vm_private_data test from is_mergeable_vma, so
    we can still merge VM_NONLINEARs.  Of course, we could instead add another
    field to vm_area_struct.
    108e3158
fremap.c 5.46 KB