[patch] mm: vmscan: do not swap anon pages just because free+file is low

[patch] mm: vmscan: do not swap anon pages just because free+file is low

[Johannes Weiner]

Page reclaim force-scans / swaps anonymous pages when file cache drops
below the high watermark of a zone in order to prevent what little
cache remains from thrashing.

However, on bigger machines the high watermark value can be quite
large and when the workload is dominated by a static anonymous/shmem
set, the file set might just be a small window of used-once cache.  In
such situations, the VM starts swapping heavily when instead it should
be recycling the no longer used cache.

This is a longer-standing problem, but it's more likely to trigger
after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
because file pages can no longer accumulate in a single zone and are
dispersed into smaller fractions among the available zones.

To resolve this, do not force scan anon when file pages are low but
instead rely on the scan/rotation ratios to make the right prediction.

Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: <stable@kernel.org> [3.12+]
---
 mm/vmscan.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index a9c74b409681..e58e9ad5b5d1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1848,7 +1848,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
 	struct zone *zone = lruvec_zone(lruvec);
 	unsigned long anon_prio, file_prio;
 	enum scan_balance scan_balance;
-	unsigned long anon, file, free;
+	unsigned long anon, file;
 	bool force_scan = false;
 	unsigned long ap, fp;
 	enum lru_list lru;
@@ -1902,20 +1902,6 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
 		get_lru_size(lruvec, LRU_INACTIVE_FILE);
 
 	/*
-	 * If it's foreseeable that reclaiming the file cache won't be
-	 * enough to get the zone back into a desirable shape, we have
-	 * to swap.  Better start now and leave the - probably heavily
-	 * thrashing - remaining file pages alone.
-	 */
-	if (global_reclaim(sc)) {
-		free = zone_page_state(zone, NR_FREE_PAGES);
-		if (unlikely(file + free <= high_wmark_pages(zone))) {
-			scan_balance = SCAN_ANON;
-			goto out;
-		}
-	}
-
-	/*
 	 * There is enough inactive page cache, do not reclaim
 	 * anything from the anonymous working set right now.
 	 */
-- 
1.9.0

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Rik van Riel]

On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> Page reclaim force-scans / swaps anonymous pages when file cache drops
> below the high watermark of a zone in order to prevent what little
> cache remains from thrashing.
> 
> However, on bigger machines the high watermark value can be quite
> large and when the workload is dominated by a static anonymous/shmem
> set, the file set might just be a small window of used-once cache.  In
> such situations, the VM starts swapping heavily when instead it should
> be recycling the no longer used cache.
> 
> This is a longer-standing problem, but it's more likely to trigger
> after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> because file pages can no longer accumulate in a single zone and are
> dispersed into smaller fractions among the available zones.
> 
> To resolve this, do not force scan anon when file pages are low but
> instead rely on the scan/rotation ratios to make the right prediction.

I am not entirely sure that the scan/rotation ratio will be
meaningful when the page cache has been essentially depleted,
but on larger systems the distance between the low and high
watermark is gigantic, and I have no better idea on how to
fix the bug you encountered, so ...

> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: <stable@kernel.org> [3.12+]

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Mel Gorman]

On Fri, Mar 14, 2014 at 12:06:25PM -0400, Rik van Riel wrote:
> On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> > Page reclaim force-scans / swaps anonymous pages when file cache drops
> > below the high watermark of a zone in order to prevent what little
> > cache remains from thrashing.
> > 
> > However, on bigger machines the high watermark value can be quite
> > large and when the workload is dominated by a static anonymous/shmem
> > set, the file set might just be a small window of used-once cache.  In
> > such situations, the VM starts swapping heavily when instead it should
> > be recycling the no longer used cache.
> > 
> > This is a longer-standing problem, but it's more likely to trigger
> > after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> > because file pages can no longer accumulate in a single zone and are
> > dispersed into smaller fractions among the available zones.
> > 
> > To resolve this, do not force scan anon when file pages are low but
> > instead rely on the scan/rotation ratios to make the right prediction.
> 
> I am not entirely sure that the scan/rotation ratio will be
> meaningful when the page cache has been essentially depleted,
> but on larger systems the distance between the low and high
> watermark is gigantic, and I have no better idea on how to
> fix the bug you encountered, so ...
> 

I still agree with the direction in general even though I've not put
thought into this specific patch yet. We've observed a problem whereby force
reclaim was causing one or other LRU list to be trashed.  In one specific
case, the inactive file is low logic was causing problems because while
the relative size of inactive/active was taken into account, the absolute
size vs anon was not. It was not a mainline kernel and we do not have a
test configuration that properly illustrates the problem on mainline it's
on our radar that it's a potential problem. The scan/rotation ratio at the
moment does not take absolute sizes into account but we almost certainly
want to go in that direction at some stage. Hugh's patch on altering how
proportional shrinking works is also relevant.

-- 
Mel Gorman
SUSE Labs

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Hugh Dickins]

On Fri, 14 Mar 2014, Mel Gorman wrote:
> On Fri, Mar 14, 2014 at 12:06:25PM -0400, Rik van Riel wrote:
> > On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> > > Page reclaim force-scans / swaps anonymous pages when file cache drops
> > > below the high watermark of a zone in order to prevent what little
> > > cache remains from thrashing.
> > > 
> > > However, on bigger machines the high watermark value can be quite
> > > large and when the workload is dominated by a static anonymous/shmem
> > > set, the file set might just be a small window of used-once cache.  In
> > > such situations, the VM starts swapping heavily when instead it should
> > > be recycling the no longer used cache.
> > > 
> > > This is a longer-standing problem, but it's more likely to trigger
> > > after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> > > because file pages can no longer accumulate in a single zone and are
> > > dispersed into smaller fractions among the available zones.
> > > 
> > > To resolve this, do not force scan anon when file pages are low but
> > > instead rely on the scan/rotation ratios to make the right prediction.
> > 
> > I am not entirely sure that the scan/rotation ratio will be
> > meaningful when the page cache has been essentially depleted,
> > but on larger systems the distance between the low and high
> > watermark is gigantic, and I have no better idea on how to
> > fix the bug you encountered, so ...
> > 
> 
> I still agree with the direction in general even though I've not put
> thought into this specific patch yet. We've observed a problem whereby force
> reclaim was causing one or other LRU list to be trashed.  In one specific
> case, the inactive file is low logic was causing problems because while
> the relative size of inactive/active was taken into account, the absolute
> size vs anon was not. It was not a mainline kernel and we do not have a
> test configuration that properly illustrates the problem on mainline it's
> on our radar that it's a potential problem. The scan/rotation ratio at the
> moment does not take absolute sizes into account but we almost certainly
> want to go in that direction at some stage. Hugh's patch on altering how
> proportional shrinking works is also relevant.

That https://lkml.org/lkml/2014/3/13/217
is relevant, yes, but I think rather more so is
Suleiman's in https://lkml.org/lkml/2014/3/15/168

Hannes, your patch looks reasonable to me, and as I read it would
be well complemented by Suleiman's and mine; but I do worry that
the "scan_balance = SCAN_ANON" block you're removing was inserted
for good reason, and its removal bring complaint from some direction.

By the way, I notice you marked yours for stable [3.12+]:
if it's for stable at all, shouldn't it be for 3.9+?
(well, maybe nobody's doing a 3.9.N.M but 3.10.N is still alive).

Hugh

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Johannes Weiner]

On Sat, Mar 15, 2014 at 09:20:16PM -0700, Hugh Dickins wrote:
> On Fri, 14 Mar 2014, Mel Gorman wrote:
> > On Fri, Mar 14, 2014 at 12:06:25PM -0400, Rik van Riel wrote:
> > > On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> > > > Page reclaim force-scans / swaps anonymous pages when file cache drops
> > > > below the high watermark of a zone in order to prevent what little
> > > > cache remains from thrashing.
> > > > 
> > > > However, on bigger machines the high watermark value can be quite
> > > > large and when the workload is dominated by a static anonymous/shmem
> > > > set, the file set might just be a small window of used-once cache.  In
> > > > such situations, the VM starts swapping heavily when instead it should
> > > > be recycling the no longer used cache.
> > > > 
> > > > This is a longer-standing problem, but it's more likely to trigger
> > > > after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> > > > because file pages can no longer accumulate in a single zone and are
> > > > dispersed into smaller fractions among the available zones.
> > > > 
> > > > To resolve this, do not force scan anon when file pages are low but
> > > > instead rely on the scan/rotation ratios to make the right prediction.
> > > 
> > > I am not entirely sure that the scan/rotation ratio will be
> > > meaningful when the page cache has been essentially depleted,
> > > but on larger systems the distance between the low and high
> > > watermark is gigantic, and I have no better idea on how to
> > > fix the bug you encountered, so ...
> > > 
> > 
> > I still agree with the direction in general even though I've not put
> > thought into this specific patch yet. We've observed a problem whereby force
> > reclaim was causing one or other LRU list to be trashed.  In one specific
> > case, the inactive file is low logic was causing problems because while
> > the relative size of inactive/active was taken into account, the absolute
> > size vs anon was not. It was not a mainline kernel and we do not have a
> > test configuration that properly illustrates the problem on mainline it's
> > on our radar that it's a potential problem. The scan/rotation ratio at the
> > moment does not take absolute sizes into account but we almost certainly
> > want to go in that direction at some stage. Hugh's patch on altering how
> > proportional shrinking works is also relevant.
> 
> That https://lkml.org/lkml/2014/3/13/217
> is relevant, yes, but I think rather more so is
> Suleiman's in https://lkml.org/lkml/2014/3/15/168
> 
> Hannes, your patch looks reasonable to me, and as I read it would
> be well complemented by Suleiman's and mine; but I do worry that
> the "scan_balance = SCAN_ANON" block you're removing was inserted
> for good reason, and its removal bring complaint from some direction.

It's been introduced with the original LRU split patch but there is no
explanation why.  Rik's concern now was that the scan/rotate numbers
might not be too meaningful with very little cache.

> By the way, I notice you marked yours for stable [3.12+]:
> if it's for stable at all, shouldn't it be for 3.9+?
> (well, maybe nobody's doing a 3.9.N.M but 3.10.N is still alive).

The code I'm removing is fairly old and it's only been reported to
create problems starting with the fair zone allocator in 3.12.

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Hugh Dickins]

On Mon, 17 Mar 2014, Johannes Weiner wrote:
> On Sat, Mar 15, 2014 at 09:20:16PM -0700, Hugh Dickins wrote:
> > 
> > Hannes, your patch looks reasonable to me, and as I read it would
> > be well complemented by Suleiman's and mine; but I do worry that
> > the "scan_balance = SCAN_ANON" block you're removing was inserted
> > for good reason, and its removal bring complaint from some direction.
> 
> It's been introduced with the original LRU split patch but there is no
> explanation why.  Rik's concern now was that the scan/rotate numbers
> might not be too meaningful with very little cache.
> 
> > By the way, I notice you marked yours for stable [3.12+]:
> > if it's for stable at all, shouldn't it be for 3.9+?
> > (well, maybe nobody's doing a 3.9.N.M but 3.10.N is still alive).
> 
> The code I'm removing is fairly old and it's only been reported to
> create problems starting with the fair zone allocator in 3.12.

Ah, you're right, thanks.

Hugh

--
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>

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Rafael Aquini]

On Fri, Mar 14, 2014 at 11:35:02AM -0400, Johannes Weiner wrote:
> Page reclaim force-scans / swaps anonymous pages when file cache drops
> below the high watermark of a zone in order to prevent what little
> cache remains from thrashing.
> 
> However, on bigger machines the high watermark value can be quite
> large and when the workload is dominated by a static anonymous/shmem
> set, the file set might just be a small window of used-once cache.  In
> such situations, the VM starts swapping heavily when instead it should
> be recycling the no longer used cache.
> 
> This is a longer-standing problem, but it's more likely to trigger
> after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> because file pages can no longer accumulate in a single zone and are
> dispersed into smaller fractions among the available zones.
> 
> To resolve this, do not force scan anon when file pages are low but
> instead rely on the scan/rotation ratios to make the right prediction.
> 
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: <stable@kernel.org> [3.12+]
> ---

Acked-by: Rafael Aquini <aquini@redhat.com>

>  mm/vmscan.c | 16 +---------------
>  1 file changed, 1 insertion(+), 15 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a9c74b409681..e58e9ad5b5d1 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1848,7 +1848,7 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>  	struct zone *zone = lruvec_zone(lruvec);
>  	unsigned long anon_prio, file_prio;
>  	enum scan_balance scan_balance;
> -	unsigned long anon, file, free;
> +	unsigned long anon, file;
>  	bool force_scan = false;
>  	unsigned long ap, fp;
>  	enum lru_list lru;
> @@ -1902,20 +1902,6 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
>  		get_lru_size(lruvec, LRU_INACTIVE_FILE);
>  
>  	/*
> -	 * If it's foreseeable that reclaiming the file cache won't be
> -	 * enough to get the zone back into a desirable shape, we have
> -	 * to swap.  Better start now and leave the - probably heavily
> -	 * thrashing - remaining file pages alone.
> -	 */
> -	if (global_reclaim(sc)) {
> -		free = zone_page_state(zone, NR_FREE_PAGES);
> -		if (unlikely(file + free <= high_wmark_pages(zone))) {
> -			scan_balance = SCAN_ANON;
> -			goto out;
> -		}
> -	}
> -
> -	/*
>  	 * There is enough inactive page cache, do not reclaim
>  	 * anything from the anonymous working set right now.
>  	 */
> -- 
> 1.9.0
> 
> --
> 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>

--
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>