Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit

[Knut Petersen <Knut_Petersen@t-online.de>]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On 18.09.2013 11:10, Daniel Vetter wrote:

Just now I prepared a patch changing the same function in vmscan.c
> Also, this needs to be rebased to the new shrinker api in 3.12, I
> simply haven't rolled my trees forward yet.

Well, you should. Since commit 81e49f  shrinker->count_objects might be
set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often:

[ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=-xxxxxxxxx

The kernel emitted a few thousand log lines like the one quoted above during the
last few days on my system.

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2cff0d4..d81f6e0 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink,
>   			total_scan = max_pass;
>   		}
>   
> +		/* Always try to shrink a bit to make forward progress. */
> +		if (shrinker->evicts_to_page_lru)
> +			total_scan = max_t(long, total_scan, batch_size);
> +
At that place the error message is already emitted.
>   		/*
>   		 * We need to avoid excessive windup on filesystem shrinkers
>   		 * due to large numbers of GFP_NOFS allocations causing the

Have a look at the attached patch. It fixes my problem with the erroneous/misleading
error messages, and I think it´s right to just bail out early if SHRINK_STOP is found.

Do you agree ?

cu,
  Knut


[-- Attachment #2: 0001-mm-respect-SHRINK_STOP-in-shrink_slab_node.patch --]
[-- Type: text/x-patch, Size: 1128 bytes --]

>From 75ae570ce7b0bb6b40c76beb18fc075e9af3127a Mon Sep 17 00:00:00 2001
From: Knut Petersen <Knut_Petersen@t-online.de>
Date: Wed, 18 Sep 2013 12:06:33 +0200
Subject: [PATCH] mm: respect SHRINK_STOP in shrink_slab_node()

Since commit 81e49f811404f428a9d9a63295a0c267e802fa12
i915_gem_inactive_count() might return SHRINK_STOP.

Unfortunately SHRINK_STOP is not handled propperly in
shrink_slab_node(), causing a system log cluttered with
kernel error messages complaining about "negative objects
to delete".

I think the proper way of handling SHRINK_STOP is obvious,
we should obey ;-)

Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
---
 mm/vmscan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8ed1b77..b1e6f0d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -244,6 +244,8 @@ shrink_slab_node(struct shrink_control *shrinkctl, struct shrinker *shrinker,
 	max_pass = shrinker->count_objects(shrinker, shrinkctl);
 	if (max_pass == 0)
 		return 0;
+	if (max_pass == SHRINK_STOP)
+		return 0;
 
 	/*
 	 * copy the current shrinker scan count into a local variable
-- 
1.8.1.4