Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp49393imm; Tue, 3 Jul 2018 13:42:31 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKc/Gf8WRdgoVLCV80JAxuuEmtYE/pZ34vekUiXK1OAYUphSiNls4Zc4BShsZUQII00Mvyf X-Received: by 2002:a65:4d4b:: with SMTP id j11-v6mr26920321pgt.430.1530650551884; Tue, 03 Jul 2018 13:42:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530650551; cv=none; d=google.com; s=arc-20160816; b=uCLTS3dD1NdGxI7Ycog967Q9U86Qnzr32GpOlxmBT1DQKaAcY6D+HY5JmJNJN3e4jy d47laYgOVr2Xep3qSf2mKjZ84oi4sQxiqQm4sealiO+aYAJg5sezvseotIIU4MpeNTQJ DNPzt4jg9dzMJ22i/jQyH0RnF4rZlueayZh6ndwEQWbVpMe9YfFhAh4xD9EDugzaTpsv CTgL/I0y+Ccn2BJdXJwpN/CCsDRWaWNs01m2OW5BlxOlhAiA/W+FTzHKDXBSCeemAwad DT0KPkAHNCBBjqK6yOrW7FQ/3zmeCOMMDRuTXAQ+QOVxZH+aZen9S/O401/ifVDZkzES 8BbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=CPn0NVnH2URMZrsLzlODPsyWaUOm/CG4KE+VCwnXXSI=; b=xW6kQIdjC9Qbu6m6YSbKqtwhcSsd2nlVkMWDAtPpKv9avYHrXose1APv2sIy2Wr6hO JtIE/O/fMUIDdIaWYhLAnrrr8FOqAYWP0p9qTmjZxCnFbhPrZnfsfdfhjzzY7lnS5kJe afQa76hJDqYsoanT7IB7WGfoTS5W3YDrLhaSlOu0nu+r/CsnANjQ4IOcwd52UAI3x67+ ezJCR9eFYtYpon22hm23h8bgiQCcObW9Qke2YIP9jRFxQj6ibZXoN/XK6GFpAqbDIH+S 0xiATDHvCoqEu9PoPkffy9FpKgFR89Jz749M0WPT5GbLABf20r4aZbluPhU76gmB+Eow pCCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u1-v6si1214237plj.43.2018.07.03.13.42.17; Tue, 03 Jul 2018 13:42:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753119AbeGCUk0 (ORCPT + 99 others); Tue, 3 Jul 2018 16:40:26 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:43212 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753038AbeGCUkY (ORCPT ); Tue, 3 Jul 2018 16:40:24 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.87 #1 (Red Hat Linux)) id 1faS4k-0008JF-53; Tue, 03 Jul 2018 20:39:02 +0000 Date: Tue, 3 Jul 2018 21:39:02 +0100 From: Al Viro To: Matthew Wilcox Cc: Shakeel Butt , Kirill Tkhai , Vladimir Davydov , Johannes Weiner , Michal Hocko , Thomas Gleixner , Philippe Ombredanne , stummala@codeaurora.org, gregkh@linuxfoundation.org, Stephen Rothwell , Roman Gushchin , mka@chromium.org, Tetsuo Handa , Chris Wilson , longman@redhat.com, Minchan Kim , Huang Ying , Mel Gorman , jbacik@fb.com, Guenter Roeck , LKML , Linux MM , lirongqing@baidu.com, Andrey Ryabinin , Andrew Morton Subject: Re: [PATCH v8 03/17] mm: Assign id to every memcg-aware shrinker Message-ID: <20180703203901.GV30522@ZenIV.linux.org.uk> References: <153063036670.1818.16010062622751502.stgit@localhost.localdomain> <153063054586.1818.6041047871606697364.stgit@localhost.localdomain> <20180703152723.GB21590@bombadil.infradead.org> <20180703174744.GB4834@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180703174744.GB4834@bombadil.infradead.org> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 03, 2018 at 10:47:44AM -0700, Matthew Wilcox wrote: > On Tue, Jul 03, 2018 at 08:46:28AM -0700, Shakeel Butt wrote: > > On Tue, Jul 3, 2018 at 8:27 AM Matthew Wilcox wrote: > > > This will actually reduce the size of each shrinker and be more > > > cache-efficient when calling the shrinkers. I think we can also get > > > rid of the shrinker_rwsem eventually, but let's leave it for now. > > > > Can you explain how you envision shrinker_rwsem can be removed? I am > > very much interested in doing that. > > Sure. Right now we have 3 uses of shrinker_rwsem -- two for adding and > removing shrinkers to the list and one for walking the list. If we switch > to an IDR then we can use a spinlock for adding/removing shrinkers and > the RCU read lock for looking up an entry in the IDR each iteration of > the loop. > > We'd need to stop the shrinker from disappearing underneath us while we > drop the RCU lock, so we'd need a refcount in the shrinker, and to free > the shrinkers using RCU. We do similar things for other data structures, > so this is all pretty well understood. struct super_block { ... struct shrinker s_shrink; /* per-sb shrinker handle */ ... } What was that about refcount in the shrinker and taking over the lifetime rules of the objects it might be embedded into, again?