From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by kanga.kvack.org (Postfix) with ESMTP id D40606B0036 for ; Tue, 27 May 2014 17:19:18 -0400 (EDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so9855632pbb.5 for ; Tue, 27 May 2014 14:19:18 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [2607:f8b0:400e:c01::22b]) by mx.google.com with ESMTPS id tz6si20404739pbc.165.2014.05.27.14.19.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 14:19:18 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id up15so9953777pbc.30 for ; Tue, 27 May 2014 14:19:17 -0700 (PDT) Date: Tue, 27 May 2014 14:17:59 -0700 (PDT) From: Hugh Dickins Subject: Re: [PATCH 0/3] Shrinkers and proportional reclaim In-Reply-To: <20140527023751.GB8554@dastard> 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 Sender: owner-linux-mm@kvack.org List-ID: To: Dave Chinner Cc: Mel Gorman , Andrew Morton , Johannes Weiner , Tim Chen , Yuanhan Liu , Bob Liu , Jan Kara , Rik van Riel , Linux Kernel , Linux-MM , Linux-FSDevel 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