Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp6279601iog; Thu, 23 Jun 2022 15:38:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t6mRfrRYGDk8nFxf7utWPFMh7Y4tisX+YNd68bupvsqNehXusiG296sTL5i7H4/GtagkQt X-Received: by 2002:a17:906:a3ca:b0:726:2bd2:87bc with SMTP id ca10-20020a170906a3ca00b007262bd287bcmr2246080ejb.226.1656023881537; Thu, 23 Jun 2022 15:38:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656023881; cv=none; d=google.com; s=arc-20160816; b=uliFyoAOVqoDgZXq+9CI0pPQ1AYVw2YRPn9c/rzVQNKJDsHKul4KyeDCe+Ybzbd/hG 4d2sm/zhzjq3Oyk84v0UGPpGJ3SBKVn2xRQsTts2rkRyuAunFuDM3bU2FE7qTtQExPS7 p6bATwZoL8TBc/yoow8JSfNp8r/tDGh1xcFrZkXQ7snOzd6jygkZsQyhu4xBeMA9NnKt 0bfoxXuBKzdqPPnUHWvXyIIkSc9hqwm1LbC2XqQtHoFFKHnHJJv1EwhtWTFelG8kBe5K HfPVumLq91FZy1GxrGGWseguQp92uiKEqvOFkI+JEdgxHLi3dfxJy84lHkuD6d07qB5b Fmog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=q7seKQ/x/w7hRaA4A6MnMBktfFUl73PwO+joOzjXdog=; b=h3f2OlDMH8KGkd8ImixuIHAGtdJZ89BQktkN+udhl9vN+n8NuP4ksPBarX7NfaU+4p 9rKtDVRZydJZde5pVUI0lox3TSPqfxt1lqnxZGrW4Z3BP071YE9KbLt96lKtf2D6V6FH dczRWyk8+0iMLPfdDmz+BEzvVg6zbXTXsRJlFOP3I5p7zeAq4IV8xkvqRnt3I/636DbM v69TnoZOH5Zn0SkNZBo0QjjjyQY31S9PrysqTarPcAfXzQ5cOSJzblP6ugUthxwWXVJy 2zNHPxPwhzAiNmF7iXY5kERREyhcuWrXJpSj1+BSsfdHM2sJJcaULdh3Hc80qsz1bN0t hZAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id he17-20020a1709073d9100b00715867834e3si627268ejc.506.2022.06.23.15.37.02; Thu, 23 Jun 2022 15:38:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229553AbiFWWd1 (ORCPT + 99 others); Thu, 23 Jun 2022 18:33:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60582 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiFWWd0 (ORCPT ); Thu, 23 Jun 2022 18:33:26 -0400 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F22A849930; Thu, 23 Jun 2022 15:33:23 -0700 (PDT) Received: from dread.disaster.area (pa49-181-2-147.pa.nsw.optusnet.com.au [49.181.2.147]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 476F85ECC7F; Fri, 24 Jun 2022 08:33:22 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1o4VO4-00AGXa-Gs; Fri, 24 Jun 2022 08:33:20 +1000 Date: Fri, 24 Jun 2022 08:33:20 +1000 From: Dave Chinner To: Chuck Lever III Cc: Linux NFS Mailing List , netdev , "tgraf@suug.ch" , Jeff Layton Subject: Re: [PATCH RFC 29/30] NFSD: Convert the filecache to use rhashtable Message-ID: <20220623223320.GG1098723@dread.disaster.area> References: <165590626293.75778.9843437418112335153.stgit@manet.1015granger.net> <165590735674.75778.2489188434203366753.stgit@manet.1015granger.net> <20220623003822.GF1098723@dread.disaster.area> <1BB6647C-799E-463F-BF63-55B48450FF29@oracle.com> <2F100B0A-04F2-496D-B59F-A90493D20439@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2F100B0A-04F2-496D-B59F-A90493D20439@oracle.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=OJNEYQWB c=1 sm=1 tr=0 ts=62b4ea33 a=ivVLWpVy4j68lT4lJFbQgw==:117 a=ivVLWpVy4j68lT4lJFbQgw==:17 a=IkcTkHD0fZMA:10 a=JPEYwPQDsx4A:10 a=07d9gI8wAAAA:8 a=7-415B0cAAAA:8 a=oSJpYEgRxW49ZuJqY5AA:9 a=QEXdDO2ut3YA:10 a=e2CUPOnPG4QKp8I52DXD:22 a=biEYGPWJfzWAr4FL6Ov7:22 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Jun 23, 2022 at 05:27:20PM +0000, Chuck Lever III wrote: > Also I just found Neil's nice rhashtable explainer: > > https://lwn.net/Articles/751374/ > > Where he writes that: > > > Sometimes you might want a hash table to potentially contain > > multiple objects for any given key. In that case you can use > > "rhltables" — rhashtables with lists of objects. > > I believe that is the case for the filecache. The hash value is > computed based on the inode pointer, and therefore there can be more > than one nfsd_file object for a particular inode (depending on who > is opening and for what access). So I think filecache needs to use > rhltable, not rhashtable. Any thoughts from rhashtable experts? Huh, I assumed the file cache was just hashing the whole key so that every object in the rht has it's own unique key and hash and there's no need to handle multiple objects per key... What are you trying to optimise by hashing only the inode *pointer* in the nfsd_file object keyspace? Cheers, Dave. -- Dave Chinner david@fromorbit.com