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 63D06ECE587 for ; Mon, 14 Oct 2019 13:06:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3328B217D9 for ; Mon, 14 Oct 2019 13:06:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3328B217D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D51DB8E0008; Mon, 14 Oct 2019 09:06:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D03178E0001; Mon, 14 Oct 2019 09:06:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF12A8E0008; Mon, 14 Oct 2019 09:06:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id A1B1E8E0001 for ; Mon, 14 Oct 2019 09:06:55 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 4CB6F4DCA for ; Mon, 14 Oct 2019 13:06:55 +0000 (UTC) X-FDA: 76042415190.02.tooth70_3c65e85b97321 X-HE-Tag: tooth70_3c65e85b97321 X-Filterd-Recvd-Size: 2737 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Oct 2019 13:06:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C04D2C049E1A; Mon, 14 Oct 2019 13:06:53 +0000 (UTC) Received: from bfoster (dhcp-41-2.bos.redhat.com [10.18.41.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2C54B1001B35; Mon, 14 Oct 2019 13:06:53 +0000 (UTC) Date: Mon, 14 Oct 2019 09:06:51 -0400 From: Brian Foster To: Christoph Hellwig Cc: Dave Chinner , 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: <20191014130651.GB12380@bfoster> 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.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 14 Oct 2019 13:06:53 +0000 (UTC) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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? FWIW, I suggested something similar on the RFC as well. Based on where that discussion ended up, however, I'm also kind of wondering why we wouldn't move towards infrastructure that supports the more granular per-item deferred tracking that is the supposed end goal (and at the same time avoid shifting this logic back and forth between the count callback and the scan/reclaim callback)..? Brian