On Sun, Oct 18, 2015 at 09:45:47PM -0700, Hugh Dickins wrote:
> While updating some mm Documentation, I came across a few straggling
> references to the non-linear vmas which were happily removed in v4.0.
> Delete them.
>
> Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
> ---
> Documentation/filesystems/proc.txt | 1
> Documentation/vm/page_migration | 10 +--
> Documentation/vm/unevictable-lru.txt | 63 +------------------------
> 3 files changed, 9 insertions(+), 65 deletions(-)
>
> --- migrat.orig/Documentation/filesystems/proc.txt 2015-09-12 18:30:13.713047477 -0700
> +++ migrat/Documentation/filesystems/proc.txt 2015-10-18 17:53:03.715313650 -0700
> @@ -474,7 +474,6 @@ manner. The codes are the following:
> ac - area is accountable
> nr - swap space is not reserved for the area
> ht - area uses huge tlb pages
> - nl - non-linear mapping
> ar - architecture specific flag
> dd - do not include area into core dump
> sd - soft-dirty flag
> --- migrat.orig/Documentation/vm/page_migration 2009-06-09 20:05:27.000000000 -0700
> +++ migrat/Documentation/vm/page_migration 2015-10-18 17:53:03.715313650 -0700
> @@ -99,12 +99,10 @@ Steps:
> 4. The new page is prepped with some settings from the old page so that
> accesses to the new page will discover a page with the correct settings.
>
> -5. All the page table references to the page are converted
> - to migration entries or dropped (nonlinear vmas).
> - This decrease the mapcount of a page. If the resulting
> - mapcount is not zero then we do not migrate the page.
> - All user space processes that attempt to access the page
> - will now wait on the page lock.
> +5. All the page table references to the page are converted to migration
> + entries. This decreases the mapcount of a page. If the resulting
> + mapcount is not zero then we do not migrate the page. All user space
> + processes that attempt to access the page will now wait on the page lock.
>
> 6. The radix tree lock is taken. This will cause all processes trying
> to access the page via the mapping to block on the radix tree spinlock.
> --- migrat.orig/Documentation/vm/unevictable-lru.txt 2015-08-30 11:34:09.000000000 -0700
> +++ migrat/Documentation/vm/unevictable-lru.txt 2015-10-18 17:53:03.716313651 -0700
> @@ -552,63 +552,17 @@ different reverse map mechanisms.
> is really unevictable or not. In this case, try_to_unmap_anon() will
> return SWAP_AGAIN.
>
> - (*) try_to_unmap_file() - linear mappings
> + (*) try_to_unmap_file()
>
> Unmapping of a mapped file page works the same as for anonymous mappings,
> except that the scan visits all VMAs that map the page's index/page offset
> - in the page's mapping's reverse map priority search tree. It also visits
> - each VMA in the page's mapping's non-linear list, if the list is
> - non-empty.
> + in the page's mapping's reverse map interval search tree.
>
> As for anonymous pages, on encountering a VM_LOCKED VMA for a mapped file
> page, try_to_unmap_file() will attempt to acquire the associated
> mm_struct's mmap semaphore to mlock the page, returning SWAP_MLOCK if this
> is successful, and SWAP_AGAIN, if not.
>
> - (*) try_to_unmap_file() - non-linear mappings
> -
> - If a page's mapping contains a non-empty non-linear mapping VMA list, then
> - try_to_un{map|lock}() must also visit each VMA in that list to determine
> - whether the page is mapped in a VM_LOCKED VMA. Again, the scan must visit
> - all VMAs in the non-linear list to ensure that the pages is not/should not
> - be mlocked.
> -
> - If a VM_LOCKED VMA is found in the list, the scan could terminate.
> - However, there is no easy way to determine whether the page is actually
> - mapped in a given VMA - either for unmapping or testing whether the
> - VM_LOCKED VMA actually pins the page.
> -
> - try_to_unmap_file() handles non-linear mappings by scanning a certain
> - number of pages - a "cluster" - in each non-linear VMA associated with the
> - page's mapping, for each file mapped page that vmscan tries to unmap. If
> - this happens to unmap the page we're trying to unmap, try_to_unmap() will
> - notice this on return (page_mapcount(page) will be 0) and return
> - SWAP_SUCCESS. Otherwise, it will return SWAP_AGAIN, causing vmscan to
> - recirculate this page. We take advantage of the cluster scan in
> - try_to_unmap_cluster() as follows:
> -
> - For each non-linear VMA, try_to_unmap_cluster() attempts to acquire the
> - mmap semaphore of the associated mm_struct for read without blocking.
> -
> - If this attempt is successful and the VMA is VM_LOCKED,
> - try_to_unmap_cluster() will retain the mmap semaphore for the scan;
> - otherwise it drops it here.
> -
> - Then, for each page in the cluster, if we're holding the mmap semaphore
> - for a locked VMA, try_to_unmap_cluster() calls mlock_vma_page() to
> - mlock the page. This call is a no-op if the page is already locked,
> - but will mlock any pages in the non-linear mapping that happen to be
> - unlocked.
> -
> - If one of the pages so mlocked is the page passed in to try_to_unmap(),
> - try_to_unmap_cluster() will return SWAP_MLOCK, rather than the default
> - SWAP_AGAIN. This will allow vmscan to cull the page, rather than
> - recirculating it on the inactive list.
> -
> - Again, if try_to_unmap_cluster() cannot acquire the VMA's mmap sem, it
> - returns SWAP_AGAIN, indicating that the page is mapped by a VM_LOCKED
> - VMA, but couldn't be mlocked.
> -
>
> try_to_munlock() REVERSE MAP SCAN
> ---------------------------------
> @@ -625,10 +579,9 @@ introduced a variant of try_to_unmap() c
> try_to_munlock() calls the same functions as try_to_unmap() for anonymous and
> mapped file pages with an additional argument specifying unlock versus unmap
> processing. Again, these functions walk the respective reverse maps looking
> -for VM_LOCKED VMAs. When such a VMA is found for anonymous pages and file
> -pages mapped in linear VMAs, as in the try_to_unmap() case, the functions
> -attempt to acquire the associated mmap semaphore, mlock the page via
> -mlock_vma_page() and return SWAP_MLOCK. This effectively undoes the
> +for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case,
> +the functions attempt to acquire the associated mmap semaphore, mlock the page
> +via mlock_vma_page() and return SWAP_MLOCK. This effectively undoes the
> pre-clearing of the page's PG_mlocked done by munlock_vma_page.
>
> If try_to_unmap() is unable to acquire a VM_LOCKED VMA's associated mmap
> @@ -636,12 +589,6 @@ semaphore, it will return SWAP_AGAIN. T
> recycle the page on the inactive list and hope that it has better luck with the
> page next time.
>
> -For file pages mapped into non-linear VMAs, the try_to_munlock() logic works
> -slightly differently. On encountering a VM_LOCKED non-linear VMA that might
> -map the page, try_to_munlock() returns SWAP_AGAIN without actually mlocking the
> -page. munlock_vma_page() will just leave the page unlocked and let vmscan deal
> -with it - the usual fallback position.
> -
> Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's
> reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA.
> However, the scan can terminate when it encounters a VM_LOCKED VMA and can
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxx. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>