lkml.org 
[lkml]   [2013]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
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

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
\
 
 \ /
  Last update: 2013-09-18 13:01    [W:0.096 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site