From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753442AbaE0XCH (ORCPT ); Tue, 27 May 2014 19:02:07 -0400 Received: from mail-ig0-f174.google.com ([209.85.213.174]:55749 "EHLO mail-ig0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752823AbaE0XCF (ORCPT ); Tue, 27 May 2014 19:02:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <1400749779-24879-1-git-send-email-mgorman@suse.de> <20140527023751.GB8554@dastard> Date: Wed, 28 May 2014 03:02:04 +0400 Message-ID: Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim From: Konstantin Khlebnikov To: Hugh Dickins Cc: Dave Chinner , Mel Gorman , Andrew Morton , Johannes Weiner , Tim Chen , Yuanhan Liu , Bob Liu , Jan Kara , Rik van Riel , Linux Kernel , Linux-MM , Linux-FSDevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 28, 2014 at 1:17 AM, Hugh Dickins wrote: > 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]. Maybe shrinker could accumulate fraction nr_pages_scanned / lru_pages instead of exact amount of required work? Count of shrinkable objects might be calculated later, when shrinker is called from a suitable context and can actualy do something.