From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AIpwx4/blGPEn0BQNhT56L3i4NDlApviGtpjwqOrIVOL85+7zngbh3yrvvppaT4gsfX+uXC2eClh ARC-Seal: i=1; a=rsa-sha256; t=1523936157; cv=none; d=google.com; s=arc-20160816; b=z5+ynHPFm5w+XmQGdNd5qhSrwKao7evzNgGlQ6+gFzox2jToxSI/TB9/RxRo/zoGZ8 PQDA6ASk+v0n711LRCpXxfqpGZl7tyMcnqtAlQLbkYLfj4CxUSCzZZ6RsTmafyazqi2m ZNiE3xvnOiu24vccDb8rNVldbnrrqvMMlB/NdpRBBtVWTOOmSgfIillCRzbG/UqYTDd9 ooOe0OcF6fd1fPl/LM0WYTwgPgIG5pbw37JfQvr6UqV//3MFuaiiZEahyg1S7UiG7Kci 7E3zU7jhLwselXb1pNz9uhwG0t5YL3rIoY2xDzfyQJM38Q1U0ayydw0rbCLn292PvH1E AYyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:dkim-signature:arc-authentication-results; bh=rVCpwtdfBVMDGYDBpaPU3gzx4+mNvHvpY8x6oxTpyhY=; b=XXoiYB8Du6CVFymGVSW7Fimkg/m0mzaUT5RAy0vlqjgFJXgpPB1MW4yhhLuBpXqxMv Qrj6QCpdknz6cuoIQ+JBeYbAjprp+HVYedkw8LnfugzvBT2Cb5kUXP2/DxSbYe6xuKMm S3imqz7vy/62/utVMAlvR515lWMBW0LttB2hDAdWbaYU22DucZatX6JDCMoZ+ukYAZ70 +/1vBUCzoo7JGewvk4Ug2kCi7b8h1cAjpkwPoSHTl22I8QR2CDh4Y/KdTFTmyunNz4Rn saKfKysNPt3iLQrvi2QQFGDYQtpZDP3uk/p+N1f14ZEzrucLdeiroYb44zeJCejJ92tU HyZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=Jm6z7plb; spf=pass (google.com: best guess record for domain of jsimmons@infradead.org designates 2001:8b0:10b:1236::1 as permitted sender) smtp.mailfrom=jsimmons@infradead.org Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=Jm6z7plb; spf=pass (google.com: best guess record for domain of jsimmons@infradead.org designates 2001:8b0:10b:1236::1 as permitted sender) smtp.mailfrom=jsimmons@infradead.org Date: Tue, 17 Apr 2018 04:35:43 +0100 (BST) From: James Simmons To: NeilBrown cc: Oleg Drokin , Greg Kroah-Hartman , Andreas Dilger , Linux Kernel Mailing List , Lustre Development List Subject: Re: [PATCH 00/20] staging: lustre: convert to rhashtable In-Reply-To: <152348312863.12394.11915752362061083241.stgit@noble> Message-ID: References: <152348312863.12394.11915752362061083241.stgit@noble> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180417_043543_766628_E51A92F1 X-CRM114-Status: GOOD ( 31.46 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary: Content analysis details: (-0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1597488463998050383?= X-GMAIL-MSGID: =?utf-8?q?1597962880233421595?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > libcfs in lustre has a resizeable hashtable. > Linux already has a resizeable hashtable, rhashtable, which is better > is most metrics. See https://lwn.net/Articles/751374/ in a few days > for an introduction to rhashtable. Thansk for starting this work. I was think about cleaning the libcfs hash but your port to rhashtables is way better. How did you gather metrics to see that rhashtable was better than libcfs hash? > This series converts lustre to use rhashtable. This affects several > different tables, and each is different is various ways. > > There are two outstanding issues. One is that a bug in rhashtable > means that we cannot enable auto-shrinking in one of the tables. That > is documented as appropriate and should be fixed soon. > > The other is that rhashtable has an atomic_t which counts the elements > in a hash table. At least one table in lustre went to some trouble to > avoid any table-wide atomics, so that could lead to a regression. > I'm hoping that rhashtable can be enhanced with the option of a > per-cpu counter, or similar. > This doesn't sound quite ready to land just yet. This will have to do some soak testing and a larger scope of test to make sure no new regressions happen. Believe me I did work to make lustre work better on tickless systems, which I'm preparing for the linux client, and small changes could break things in interesting ways. I will port the rhashtable change to the Intel developement branch and get people more familar with the hash code to look at it. > I have enabled automatic shrinking on all tables where it makes sense > and doesn't trigger the bug. I have also removed all hints concerning > min/max size - I cannot see how these could be useful. > > The dump_pgcache debugfs file provided some interesting challenges. I > think I have cleaned it up enough so that it all makes sense. An > extra pair of eyes examining that code in particular would be > appreciated. > > This series passes all the same tests that pass before the patches are > applied. > > Thanks, > NeilBrown > > > --- > > NeilBrown (20): > staging: lustre: ptlrpc: convert conn_hash to rhashtable > staging: lustre: convert lov_pool to use rhashtable > staging: lustre: convert obd uuid hash to rhashtable > staging: lustre: convert osc_quota hash to rhashtable > staging: lustre: separate buckets from ldlm hash table > staging: lustre: ldlm: add a counter to the per-namespace data > staging: lustre: ldlm: store name directly in namespace. > staging: lustre: simplify ldlm_ns_hash_defs[] > staging: lustre: convert ldlm_resource hash to rhashtable. > staging: lustre: make struct lu_site_bkt_data private > staging: lustre: lu_object: discard extra lru count. > staging: lustre: lu_object: factor out extra per-bucket data > staging: lustre: lu_object: move retry logic inside htable_lookup > staging: lustre: fold lu_object_new() into lu_object_find_at() > staging: lustre: llite: use more private data in dump_pgcache > staging: lustre: llite: remove redundant lookup in dump_pgcache > staging: lustre: use call_rcu() to free lu_object_headers > staging: lustre: change how "dump_page_cache" walks a hash table > staging: lustre: convert lu_object cache to rhashtable > staging: lustre: remove cfs_hash resizeable hashtable implementation. > > > .../staging/lustre/include/linux/libcfs/libcfs.h | 1 > .../lustre/include/linux/libcfs/libcfs_hash.h | 866 -------- > drivers/staging/lustre/lnet/libcfs/Makefile | 2 > drivers/staging/lustre/lnet/libcfs/hash.c | 2064 -------------------- > drivers/staging/lustre/lnet/libcfs/module.c | 12 > drivers/staging/lustre/lustre/include/lu_object.h | 55 - > drivers/staging/lustre/lustre/include/lustre_dlm.h | 19 > .../staging/lustre/lustre/include/lustre_export.h | 2 > drivers/staging/lustre/lustre/include/lustre_net.h | 4 > drivers/staging/lustre/lustre/include/obd.h | 11 > .../staging/lustre/lustre/include/obd_support.h | 9 > drivers/staging/lustre/lustre/ldlm/ldlm_request.c | 31 > drivers/staging/lustre/lustre/ldlm/ldlm_resource.c | 370 +--- > drivers/staging/lustre/lustre/llite/lcommon_cl.c | 8 > drivers/staging/lustre/lustre/llite/vvp_dev.c | 332 +-- > drivers/staging/lustre/lustre/llite/vvp_object.c | 9 > drivers/staging/lustre/lustre/lov/lov_internal.h | 11 > drivers/staging/lustre/lustre/lov/lov_obd.c | 12 > drivers/staging/lustre/lustre/lov/lov_object.c | 8 > drivers/staging/lustre/lustre/lov/lov_pool.c | 159 +- > drivers/staging/lustre/lustre/lov/lovsub_object.c | 9 > drivers/staging/lustre/lustre/obdclass/genops.c | 34 > drivers/staging/lustre/lustre/obdclass/lu_object.c | 564 ++--- > .../staging/lustre/lustre/obdclass/obd_config.c | 161 +- > .../staging/lustre/lustre/obdecho/echo_client.c | 8 > drivers/staging/lustre/lustre/osc/osc_internal.h | 5 > drivers/staging/lustre/lustre/osc/osc_quota.c | 136 - > drivers/staging/lustre/lustre/osc/osc_request.c | 12 > drivers/staging/lustre/lustre/ptlrpc/connection.c | 164 +- > 29 files changed, 870 insertions(+), 4208 deletions(-) > delete mode 100644 drivers/staging/lustre/include/linux/libcfs/libcfs_hash.h > delete mode 100644 drivers/staging/lustre/lnet/libcfs/hash.c > > -- > Signature > >