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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 2B32EC4361A for ; Fri, 4 Dec 2020 18:54:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7716822CA1 for ; Fri, 4 Dec 2020 18:54:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7716822CA1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5DA9D6B0036; Fri, 4 Dec 2020 13:54:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58C2F6B005C; Fri, 4 Dec 2020 13:54:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A2576B005D; Fri, 4 Dec 2020 13:54:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 34EBD6B0036 for ; Fri, 4 Dec 2020 13:54:52 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 05A77180AD81D for ; Fri, 4 Dec 2020 18:54:52 +0000 (UTC) X-FDA: 77556501624.01.hand36_4e07791273c6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id D615F1004D193 for ; Fri, 4 Dec 2020 18:54:51 +0000 (UTC) X-HE-Tag: hand36_4e07791273c6 X-Filterd-Recvd-Size: 6734 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 18:54:51 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id h20so6423704qkk.4 for ; Fri, 04 Dec 2020 10:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=rg7lrS/4cr2DIOho7mbjVZXSDz3+KMSUQybW7MPBlNA=; b=twndtQ1CF5ITaAzRNV/5rAfbKfs+6rjo4uTloJ1pRExv5sQhw1SELhyHv/uLbYchHG OTGkOYTH1eBROSNK+yTXPNY62q7M+aOkghEDJ584QyK2euCGKPBdsdakiW1Cwic33peI glBoNZbYxdxPfibwDuInPMBJ+f3IXfiGqHjz56KaIG8jGSC6Jth5BgqVuCJSCTxOL58a yWVIgJVys6vFWeVmIHMhhLOFar4qS0BX8QJzRClyQU9UjNct0DdeQLYYQyyiKHJVZUV/ axI8PAqs1DqDTd9/kv9P7gjaA66x1EatLotAAc6sXtbvkA3ugA0ba8mdPPwQlm6ycK7D aO3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rg7lrS/4cr2DIOho7mbjVZXSDz3+KMSUQybW7MPBlNA=; b=JCurPICXI24WaSyq1JvcY2TysJVwAUuCaJF2DyuqY7vcy6+dwrTSZSFBOty2WLuqSN oA9y2CgtMnCk5PGgBHp/oz5Sp0WybyD7hH1nuVsN2FxuReU0L5wYmNuClkgNno0tfh2e MxLNwKttX6E5fv6DETZQebUEKQ8E8C/Aek+o3G2SRd13bcNQdyBWyL+twPED7FgcOcH8 ABrj1HKjyc/r/zRg9hTPBGWbeoZPT4yH6n03ZLvAbyyH6Pz53ybIbcKvtgtwBj9JeEd8 wmbuPrkQpkSKmRZOu7gIFt3aOgFAtm3HLfkCkEL6qGGYs/c4ICGwx2HhRGgw2JWbsGI0 TqIQ== X-Gm-Message-State: AOAM531YHdxQ0IlFhOAY7pqgBSqZd58KNZ6SNDimsmF9SV4uAH8kNTk6 xevqFu9vwORErcwiCVutRQVCxA== X-Google-Smtp-Source: ABdhPJyQVuWk9koWKozYjk4xSbqAGSTa/BUZAQJ0yr3p51asd8OHOsW1+VTpzgu+YAEf8hAdK7BrVw== X-Received: by 2002:a37:6358:: with SMTP id x85mr10465468qkb.405.1607108090466; Fri, 04 Dec 2020 10:54:50 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:a180]) by smtp.gmail.com with ESMTPSA id 60sm1938803qth.14.2020.12.04.10.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 10:54:49 -0800 (PST) Date: Fri, 4 Dec 2020 13:52:47 -0500 From: Johannes Weiner To: Yang Shi Cc: Roman Gushchin , Kirill Tkhai , Shakeel Butt , Dave Chinner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH 4/9] mm: vmscan: use a new flag to indicate shrinker is registered Message-ID: <20201204185247.GA182921@cmpxchg.org> References: <20201202182725.265020-1-shy828301@gmail.com> <20201202182725.265020-5-shy828301@gmail.com> <20201203030104.GF1375014@carbon.DHCP.thefacebook.com> <20201203200820.GC1571588@carbon.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu, Dec 03, 2020 at 02:25:20PM -0800, Yang Shi wrote: > On Thu, Dec 3, 2020 at 12:09 PM Roman Gushchin wrote: > > > > On Wed, Dec 02, 2020 at 08:59:40PM -0800, Yang Shi wrote: > > > On Wed, Dec 2, 2020 at 7:01 PM Roman Gushchin wrote: > > > > > > > > On Wed, Dec 02, 2020 at 10:27:20AM -0800, Yang Shi wrote: > > > > > Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred. > > > > > This approach is fine with nr_deferred atthe shrinker level, but the following > > > > > patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so their > > > > > shrinker->nr_deferred would always be NULL. This would prevent the shrinkers > > > > > from unregistering correctly. > > > > > > > > > > Introduce a new "state" field to indicate if shrinker is registered or not. > > > > > We could use the highest bit of flags, but it may be a little bit complicated to > > > > > extract that bit and the flags is accessed frequently by vmscan (every time shrinker > > > > > is called). So add a new field in "struct shrinker", we may waster a little bit > > > > > memory, but it should be very few since there should be not too many registered > > > > > shrinkers on a normal system. > > > > > > > > > > Signed-off-by: Yang Shi > > > > > --- > > > > > include/linux/shrinker.h | 4 ++++ > > > > > mm/vmscan.c | 13 +++++++++---- > > > > > 2 files changed, 13 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h > > > > > index 0f80123650e2..0bb5be88e41d 100644 > > > > > --- a/include/linux/shrinker.h > > > > > +++ b/include/linux/shrinker.h > > > > > @@ -35,6 +35,9 @@ struct shrink_control { > > > > > > > > > > #define SHRINK_STOP (~0UL) > > > > > #define SHRINK_EMPTY (~0UL - 1) > > > > > + > > > > > +#define SHRINKER_REGISTERED 0x1 > > > > > + > > > > > /* > > > > > * A callback you can register to apply pressure to ageable caches. > > > > > * > > > > > @@ -66,6 +69,7 @@ struct shrinker { > > > > > long batch; /* reclaim batch size, 0 = default */ > > > > > int seeks; /* seeks to recreate an obj */ > > > > > unsigned flags; > > > > > + unsigned state; > > > > > > > > Hm, can't it be another flag? It seems like we have a plenty of free bits. > > > > > > I thought about this too. But I was not convinced by myself that > > > messing flags with state is a good practice. We may add more flags in > > > the future, so we may end up having something like: > > > > > > flag > > > flag > > > flag > > > state > > > flag > > > flag > > > ... > > > > > > Maybe we could use the highest bit for state? > > > > Or just > > state > > flag > > flag > > flag > > flag > > flag > > ... > > > > ? > > It is fine too. We should not add more states in foreseeable future. It's always possible to shuffle things around for cleanup later on, too. We don't have to provide binary compatibility for existing flags, and changing a couple of adjacent bits isn't a big deal to keep things neat. Or am I missing something?