From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA41DCA9EA3 for ; Fri, 18 Oct 2019 07:59:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BB5C5222C9 for ; Fri, 18 Oct 2019 07:59:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BB5C5222C9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4AB988E000E; Fri, 18 Oct 2019 03:59:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45CAF8E0003; Fri, 18 Oct 2019 03:59:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34B6A8E000E; Fri, 18 Oct 2019 03:59:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 143078E0003 for ; Fri, 18 Oct 2019 03:59:45 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 8EEF718017385 for ; Fri, 18 Oct 2019 07:59:44 +0000 (UTC) X-FDA: 76056156288.14.bit04_54ffe4fb03d1e X-HE-Tag: bit04_54ffe4fb03d1e X-Filterd-Recvd-Size: 2896 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Fri, 18 Oct 2019 07:59:43 +0000 (UTC) Received: from dread.disaster.area (pa49-179-0-183.pa.nsw.optusnet.com.au [49.179.0.183]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 6E763363ED4; Fri, 18 Oct 2019 18:59:39 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.2) (envelope-from ) id 1iLNAh-0005qf-8c; Fri, 18 Oct 2019 18:59:39 +1100 Date: Fri, 18 Oct 2019 18:59:39 +1100 From: Dave Chinner To: Christoph Hellwig Cc: linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 08/26] mm: directed shrinker work deferral Message-ID: <20191018075939.GP16973@dread.disaster.area> References: <20191009032124.10541-1-david@fromorbit.com> <20191009032124.10541-9-david@fromorbit.com> <20191014084604.GA11758@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191014084604.GA11758@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=G6BsK5s5 c=1 sm=1 tr=0 a=52fyy8O0dbGPTevbDZN8bg==:117 a=52fyy8O0dbGPTevbDZN8bg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=XobE76Q3jBoA:10 a=20KFwNOVAAAA:8 a=7-415B0cAAAA:8 a=KK2cpZmtYymXl3zhzrcA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000029, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 14, 2019 at 01:46:04AM -0700, Christoph Hellwig wrote: > On Wed, Oct 09, 2019 at 02:21:06PM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > Introduce a mechanism for ->count_objects() to indicate to the > > shrinker infrastructure that the reclaim context will not allow > > scanning work to be done and so the work it decides is necessary > > needs to be deferred. > > > > This simplifies the code by separating out the accounting of > > deferred work from the actual doing of the work, and allows better > > decisions to be made by the shrinekr control logic on what action it > > can take. > > I hate all this boilerplate code in the scanners. Can't we just add > a a required_gfp_mask field to struct shrinker and lift the pattern > to common code? Because the deferral isn't intended to support just deferring work from GFP_NOFS reclaim context. e.g. i915_gem_shrinker_scan() stops the shrinker if it can't get a lock to avoid recursion deadlocks. There's several other shrinkers that have similar logic that punts work to avoid deadlocks, and so they could also use deferred work to punt it kswapd.... i.e. while I currently use it for GFP_NOFS deferal, that's no the only reason for defering work... Cheers, Dave. -- Dave Chinner david@fromorbit.com