From mboxrd@z Thu Jan 1 00:00:00 1970 From: Knut Petersen Subject: Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit Date: Wed, 18 Sep 2013 13:34:23 +0200 Message-ID: <52398FBF.5060102@t-online.de> References: <1379495401-18279-1-git-send-email-daniel.vetter@ffwll.ch> <5239829F.4080601@t-online.de> <20130918105631.GS32145@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20130918105631.GS32145@phenom.ffwll.local> Sender: owner-linux-mm@kvack.org To: Linux MM , Rik van Riel , Intel Graphics Development , Johannes Weiner , LKML , DRI Development , Michal Hocko , Mel Gorman , Glauber Costa , Andrew Morton , Linus Torvalds List-Id: intel-gfx@lists.freedesktop.org > Looking at the patch which introduced these error message for you, whic= h > changed the ->count_objects return value from 0 to SHRINK_STOP your pat= ch > below to treat 0 and SHRINK_STOP equally simply reverts the functional > change. Yes, for i915* it de facto restores the old behaviour. > I don't think that's the intention behind SHRINK_STOP. But if it's the > right think to do we better revert the offending commit directly. But there is other code that also returns SHRINK_STOP. So i believe it=B4= s better to adapt shrink_slab_node() to handle SHRINK_STOP properly than to revert 81= e49f. > And since I lack clue I think that's a call for core mm guys to make. I agree. They=B4ll probably have to apply some additional changes to shrink_slab_node(). It really doesn=B4t look right to me, but they certai= nly know better what the code is supposed to do ;-) cu, Knut -- 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: email@kvack.org