From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim Date: Tue, 27 May 2014 14:17:59 -0700 (PDT) Message-ID: References: <1400749779-24879-1-git-send-email-mgorman@suse.de> <20140527023751.GB8554@dastard> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Mel Gorman , Andrew Morton , Johannes Weiner , Tim Chen , Yuanhan Liu , Bob Liu , Jan Kara , Rik van Riel , Linux Kernel , Linux-MM , Linux-FSDevel To: Dave Chinner Return-path: In-Reply-To: <20140527023751.GB8554@dastard> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 27 May 2014, Dave Chinner wrote: > On Mon, May 26, 2014 at 02:44:29PM -0700, Hugh Dickins wrote: > > > > [PATCH 4/3] fs/superblock: Avoid counting without __GFP_FS > > > > Don't waste time counting objects in super_cache_count() if no __GFP_FS: > > super_cache_scan() would only back out with SHRINK_STOP in that case. > > > > Signed-off-by: Hugh Dickins > > While you might think that's a good thing, it's not. The act of > shrinking is kept separate from the accounting of how much shrinking > needs to take place. The amount of work the shrinker can't do due > to the reclaim context is deferred until the shrinker is called in a > context where it can do work (eg. kswapd) > > Hence not accounting for work that can't be done immediately will > adversely impact the balance of the system under memory intensive > filesystem workloads. In these worklaods, almost all allocations are > done in the GFP_NOFS or GFP_NOIO contexts so not deferring the work > will will effectively stop superblock cache reclaim entirely.... Thanks for filling me in on that. At first I misunderstood you, and went off looking in the wrong direction. Now I see what you're referring to: the quantity that shrink_slab_node() accumulates in and withdraws from shrinker->nr_deferred[nid]. Right: forget my super_cache_count() __GFP_FS patch! 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: email@kvack.org