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_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 0660CC10F11 for ; Thu, 11 Apr 2019 02:49:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF0D1217D9 for ; Thu, 11 Apr 2019 02:49:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=tobin.cc header.i=@tobin.cc header.b="CczKK/Up"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Nij/jYo7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726768AbfDKCs6 (ORCPT ); Wed, 10 Apr 2019 22:48:58 -0400 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:39733 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726588AbfDKCs6 (ORCPT ); Wed, 10 Apr 2019 22:48:58 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 649D2113D7; Wed, 10 Apr 2019 22:48:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 10 Apr 2019 22:48:57 -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=fm2; bh=Ztcvo5tzwaFClMvheLNTkVLAOO9 IWg4XzDUHACT0MIk=; b=CczKK/UpqlaE8ij9ODtsMzCN51UGs5BaN3vhxw+QzQN QiBxrC9EhyYD/YSP1PLlyh5jckFIkvJo2dGY22ABQBz4ROJaLJ7NMVoZDhBW0cGf 7r32PoV8+ClgincFaKBqpEVZYYBOzSB9rRBbDSrDH+Rhr8mZs645XaJx5XaEuyOL vrosurzjoQYAg2WzwHJcSyuP2R+qBhbnETWUTZLyfrngzqPc9qcdQbokMP+xmy0g rWdCNnuXvC+k8nYe3aHDTaeFunsgx9UOKoKGV9nQjOXycahk5cVlWHY4nx5kZnje sa2caR+gXKt3FZ+6Zq4sJppDEL0HEPZGBtFJpvMirYQ== 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=Ztcvo5 tzwaFClMvheLNTkVLAOO9IWg4XzDUHACT0MIk=; b=Nij/jYo73SXKw9F3WTL7v7 2LKISPZawvwkYwwBjJ8fnt/37bdO75Gpsx1rqZhhPf633E8j63zNYoVFkLI831+N q++a5LJDjOnBzPtUiqAmb9m1x9nm9/XkUEAER6H/XQWc0E0iaVZ5PTMG0Z7cyb+J PYeJ2kTRPwAjI6xVOkUSb0HSkE67m8bMt4Jph72HQEajl+Cj7OXiBBUnpqkAP7pZ LGD0T31Kw6OL6wmy5bleLqJYmjnMOwyhcV6wZutAXbNVJVi/2k0+uUnaSxum3Zap e40lS2AaiWEzE7/k5EqEW6VfYxfMc8kOBet9Q3Yds9NgKizb14e4FfZB9EtjRvmA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfg hrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjofgfsehttdertdfo redvnecuhfhrohhmpedfvfhosghinhcuvedrucfjrghrughinhhgfdcuoehmvgesthhosg hinhdrtggtqeenucfkphepuddvgedrudejuddrudelrdduleegnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmvgesthhosghinhdrtggtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (124-171-19-194.dyn.iinet.net.au [124.171.19.194]) by mail.messagingengine.com (Postfix) with ESMTPA id E902FE4382; Wed, 10 Apr 2019 22:48:52 -0400 (EDT) Date: Thu, 11 Apr 2019 12:48:21 +1000 From: "Tobin C. Harding" To: Al Viro Cc: "Tobin C. Harding" , Andrew Morton , Roman Gushchin , Alexander Viro , Christoph Hellwig , Pekka Enberg , David Rientjes , Joonsoo Kim , Christopher Lameter , Matthew Wilcox , 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 v3 14/15] dcache: Implement partial shrink via Slab Movable Objects Message-ID: <20190411024821.GB6941@eros.localdomain> References: <20190411013441.5415-1-tobin@kernel.org> <20190411013441.5415-15-tobin@kernel.org> <20190411023322.GD2217@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190411023322.GD2217@ZenIV.linux.org.uk> 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 Thu, Apr 11, 2019 at 03:33:22AM +0100, Al Viro wrote: > On Thu, Apr 11, 2019 at 11:34:40AM +1000, Tobin C. Harding wrote: > > +/* > > + * d_isolate() - Dentry isolation callback function. > > + * @s: The dentry cache. > > + * @v: Vector of pointers to the objects to isolate. > > + * @nr: Number of objects in @v. > > + * > > + * The slab allocator is holding off frees. We can safely examine > > + * the object without the danger of it vanishing from under us. > > + */ > > +static void *d_isolate(struct kmem_cache *s, void **v, int nr) > > +{ > > + struct dentry *dentry; > > + int i; > > + > > + for (i = 0; i < nr; i++) { > > + dentry = v[i]; > > + __dget(dentry); > > + } > > + > > + return NULL; /* No need for private data */ > > +} > > Huh? This is compeletely wrong; what you need is collecting the ones > with zero refcount (and not on shrink lists) into a private list. > *NOT* bumping the refcounts at all. And do it in your isolate thing. Oh, so putting entries on a shrink list is enough to pin them? > > > +static void d_partial_shrink(struct kmem_cache *s, void **v, int nr, > > + int node, void *_unused) > > +{ > > + struct dentry *dentry; > > + LIST_HEAD(dispose); > > + int i; > > + > > + for (i = 0; i < nr; i++) { > > + dentry = v[i]; > > + spin_lock(&dentry->d_lock); > > + dentry->d_lockref.count--; > > + > > + if (dentry->d_lockref.count > 0 || > > + dentry->d_flags & DCACHE_SHRINK_LIST) { > > + spin_unlock(&dentry->d_lock); > > + continue; > > + } > > + > > + if (dentry->d_flags & DCACHE_LRU_LIST) > > + d_lru_del(dentry); > > + > > + d_shrink_add(dentry, &dispose); > > + > > + spin_unlock(&dentry->d_lock); > > + } > > Basically, that loop (sans jerking the refcount up and down) should > get moved into d_isolate(). > > + > > + if (!list_empty(&dispose)) > > + shrink_dentry_list(&dispose); > > +} > > ... with this left in d_partial_shrink(). And you obviously need some way > to pass the list from the former to the latter... Easy enough, we have a void * return value from the isolate function just for this purpose. Thanks Al, hackety hack ... Tobin