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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 568C4C04AAC for ; Tue, 21 May 2019 03:21:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25ECC2173E for ; Tue, 21 May 2019 03:21:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=tobin.cc header.i=@tobin.cc header.b="YqeOQlx5"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="6IekBOxa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726511AbfEUDVL (ORCPT ); Mon, 20 May 2019 23:21:11 -0400 Received: from new2-smtp.messagingengine.com ([66.111.4.224]:42429 "EHLO new2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726392AbfEUDVL (ORCPT ); Mon, 20 May 2019 23:21:11 -0400 X-Greylist: delayed 319 seconds by postgrey-1.27 at vger.kernel.org; Mon, 20 May 2019 23:21:10 EDT Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id B9681E3BC; Mon, 20 May 2019 23:15:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 20 May 2019 23:15:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tobin.cc; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=xK51z/4F3tloMY+tzPug3rex9T4 6SW7cKlO10EK5SOU=; b=YqeOQlx5ShquIqkxOAUmbnJsp8m/qja6Z41Yjq+YdPF VUpy3QyeomaB393THjyzAfuZlrXUwO8Krn2pJ24Ahxh5Bv9bLY9rmnOrTShDoVrZ 0yjuCDs1mZbQs5I1ciWEUqDdCXqe3i75xs7avcDFkb8uFHr9HQdloN28XH6TPgOd EPYiYg/Gj3UAr5GM4Vw7rG1EqKXfQ+N6dDbyKkFOua9jm5DDr55YrhjMvbmnYOdr kaOli+q7ca3InzmMZ3tGYMe9bROdzeUQXDV4WdJFNKkQwdWJKMyin4jdaEpvF/w1 9O861pvSU6K3IUsdGwKxvxA9MJ61cNoA9OGavASYN+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xK51z/ 4F3tloMY+tzPug3rex9T46SW7cKlO10EK5SOU=; b=6IekBOxajm2IVukVZgys4+ VFDH9sDnFB1A8ggg85ndJ9idlwUvvxh/S+1eYgLmJiVfb0vPp3A+SlHon4r/w17v XLdimeduBfCBkasf8KT4RyD9V2tSW32SYzG2NCJOCAYeFiyLxztbHRYYfgcwmedj hLtueQRXoOudV4iCDoy+Uh4PFw8JH3jdwxqXzvny0APBpEXaPk2+I+Eay9OegJ5Q wiWApBBiFbKT9wh2mYYCkskz00jhYZMzzCp7MMHr73Gm+/3jJxBX42059bNExVaO e47CPN+QULGa6FZgUU+WTO4Ab7fA2y2LzsiG6UDRwGFFP1alUc4pHMPiV6hTumyQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddtledgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdlfedtmdenucfjughrpeffhffvuffkfhggtggujgfofgesthdtredt ofervdenucfhrhhomhepfdfvohgsihhnucevrdcujfgrrhguihhnghdfuceomhgvsehtoh gsihhnrdgttgeqnecukfhppeduvdegrdduieelrdduheeirddvtdefnecurfgrrhgrmhep mhgrihhlfhhrohhmpehmvgesthhosghinhdrtggtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (124-169-156-203.dyn.iinet.net.au [124.169.156.203]) by mail.messagingengine.com (Postfix) with ESMTPA id 21E9380059; Mon, 20 May 2019 23:15:47 -0400 (EDT) Date: Tue, 21 May 2019 13:15:08 +1000 From: "Tobin C. Harding" To: Roman Gushchin Cc: "Tobin C. Harding" , Andrew Morton , Matthew Wilcox , Alexander Viro , Christoph Hellwig , Pekka Enberg , David Rientjes , Joonsoo Kim , Christopher Lameter , Miklos Szeredi , Andreas Dilger , Waiman Long , Tycho Andersen , Theodore Ts'o , Andi Kleen , David Chinner , Nick Piggin , Rik van Riel , Hugh Dickins , Jonathan Corbet , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH v5 16/16] dcache: Add CONFIG_DCACHE_SMO Message-ID: <20190521031508.GA31794@eros.localdomain> References: <20190520054017.32299-1-tobin@kernel.org> <20190520054017.32299-17-tobin@kernel.org> <20190521005740.GA9552@tower.DHCP.thefacebook.com> <20190521013118.GB25898@eros.localdomain> <20190521020530.GA18287@tower.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190521020530.GA18287@tower.DHCP.thefacebook.com> X-Mailer: Mutt 1.11.4 (2019-03-13) User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, May 21, 2019 at 02:05:38AM +0000, Roman Gushchin wrote: > On Tue, May 21, 2019 at 11:31:18AM +1000, Tobin C. Harding wrote: > > On Tue, May 21, 2019 at 12:57:47AM +0000, Roman Gushchin wrote: > > > On Mon, May 20, 2019 at 03:40:17PM +1000, Tobin C. Harding wrote: > > > > In an attempt to make the SMO patchset as non-invasive as possible add a > > > > config option CONFIG_DCACHE_SMO (under "Memory Management options") for > > > > enabling SMO for the DCACHE. Whithout this option dcache constructor is > > > > used but no other code is built in, with this option enabled slab > > > > mobility is enabled and the isolate/migrate functions are built in. > > > > > > > > Add CONFIG_DCACHE_SMO to guard the partial shrinking of the dcache via > > > > Slab Movable Objects infrastructure. > > > > > > Hm, isn't it better to make it a static branch? Or basically anything > > > that allows switching on the fly? > > > > If that is wanted, turning SMO on and off per cache, we can probably do > > this in the SMO code in SLUB. > > Not necessarily per cache, but without recompiling the kernel. > > > > > It seems that the cost of just building it in shouldn't be that high. > > > And the question if the defragmentation worth the trouble is so much > > > easier to answer if it's possible to turn it on and off without rebooting. > > > > If the question is 'is defragmentation worth the trouble for the > > dcache', I'm not sure having SMO turned off helps answer that question. > > If one doesn't shrink the dentry cache there should be very little > > overhead in having SMO enabled. So if one wants to explore this > > question then they can turn on the config option. Please correct me if > > I'm wrong. > > The problem with a config option is that it's hard to switch over. > > So just to test your changes in production a new kernel should be built, > tested and rolled out to a representative set of machines (which can be > measured in thousands of machines). Then if results are questionable, > it should be rolled back. > > What you're actually guarding is the kmem_cache_setup_mobility() call, > which can be perfectly avoided using a boot option, for example. Turning > it on and off completely dynamic isn't that hard too. > > Of course, it's up to you, it's just probably easier to find new users > of a new feature, when it's easy to test it. Ok, cool - I like it. Will add for next version. thanks, Tobin.