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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Neil Brown <neilb@suse.de>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2 7/9] NFSD: Use rhashtable for managing nfs4_file
 objects
Thread-Topic: [PATCH v2 7/9] NFSD: Use rhashtable for managing nfs4_file
 objects
Thread-Index: AQHY2Z+f4KLIvxFyZE+pJJ7lJKAPUq4IWjWAgADUNACAALMrAIABAksAgABpQgCAAR1KgA==
Date:   Thu, 13 Oct 2022 14:19:42 +0000
Message-ID: <E69F66C3-C17E-4397-8329-8B6C2D2E2F0F@oracle.com>
References: <166507275951.1802.13184584115155050247.stgit@manet.1015granger.net>
 <166507324882.1802.884870684212914640.stgit@manet.1015granger.net>
 <166544739751.14457.9018300177489236723@noble.neil.brown.name>
 <EB08B095-BF02-4B5E-8CD2-12B0201328D2@oracle.com>
 <166553144435.32740.14940127200777208215@noble.neil.brown.name>
 <4004BFE1-C887-4A53-9512-8A264E0361FF@oracle.com>
 <166560951668.32740.3528791072339550207@noble.neil.brown.name>
In-Reply-To: <166560951668.32740.3528791072339550207@noble.neil.brown.name>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b13QCl4Bz2JQsmuRe9No2oJHaRZqY6B/7NKLn2KWRdsiLEyJc2CiIg/go85x?=
 =?us-ascii?Q?C78DsquIy5HN/5AormXU6+iu/SZzJHZg1ja+SeJouh2H/P1XNrZQ5U+OeSRS?=
 =?us-ascii?Q?9NYNrv/CFy0SExOCECvmHdUQLEMp+FiWVLPoJCqBIy//IW4iZDQwCBTs0h6H?=
 =?us-ascii?Q?+UQ2dpw0RoPG7cjLYhXYYBXE4Yfii6PbmE1wV4VbTTeHn9evrNYBRS9T9xcC?=
 =?us-ascii?Q?StYdhg/7aNbVEoo0FBlUsgEqQyW7dDzPXifTGqY6DS0xNfY4lU6Ph+9lBQWg?=
 =?us-ascii?Q?Uehs2i+qqbsdw8V/gD0gdxdoBV7qxr/XVBKvaEKo1VIqM21RWvG8DVqujxdW?=
 =?us-ascii?Q?ASkdSTXXhxpU3aKzdJfgK1en2kViGzt2ZBRVQFEqXg9/YUUjd2DTGTKssp1z?=
 =?us-ascii?Q?kSyqHXqs9xqZW3qqjRf72R6ALotiYM09d/0jR39qA42l6Wm4ZKhGiFW1PKPi?=
 =?us-ascii?Q?yykDCS9ia1DodJAlNwqEbKYIWNmOkWjVM21jCAMZiZd/VxLvyK4QWIxNVBNh?=
 =?us-ascii?Q?j+dnFVXu79RKdo9RPl6ph+GhIuU8j5H5eGVh9U3k0NV+uLog2/G1fuWVSAAM?=
 =?us-ascii?Q?x+rKARQRvN5ws9yQ7XrPmJAt8S72bMVL0MrslMWUg0yVdhqMnOVVhKV1Jt/m?=
 =?us-ascii?Q?6dkRBLN5SlvxSZeUc/seOq9XBikh92Oet38Jfl2CxbBjgaUtFu7oFNPHG3oM?=
 =?us-ascii?Q?Tw9iwvchkv/oJcViMxg3XcTB1DIKRUqjkqDTW38w5pNr5k6Qp3EN+7jcMK/m?=
 =?us-ascii?Q?zacGNPr+osqcbxsZl1J0x1UjHv/srdX/H6XM0MLfmHFFSyZgud4AGccPLeXh?=
 =?us-ascii?Q?FcF3NXqUqT7t4bMbxu1+3UcWVXiK4p1ljTkVCwPMZACHJ7Z48p2mMSdxx4uu?=
 =?us-ascii?Q?RvphtEzZSwl51EK7KzARh8pDt4VPS74muH64rQwF7m2Mve5PP3jUWch+4uaK?=
 =?us-ascii?Q?Z8/yI2MyLrn06iMHmPNy94gekyzMOZCrNxN6e4jSeekW1GoXnhrCyV8qk5Ux?=
 =?us-ascii?Q?SAnYcQhV8VSAznv3+GI5xaiJ84fBFkt0Bsv6Atb0b+GgzdGXmMgJAJlse7yh?=
 =?us-ascii?Q?9nwHM9ogtxqhTw7SOJ/4SWcIaYGUYuakFjjJSxRyO9MQRurdBrAS0V9rqRDW?=
 =?us-ascii?Q?KzuRDna2sfr2/HEFSWvA3K6Duaio3+eyEbpyceHcU6bL10ENdmZBMz1NUTNr?=
 =?us-ascii?Q?ygZC5VWNAMtjGs5JCWbpZA37gxoUIZpVB81W2WfQWlqcsvjyEuyqz9G2eIxS?=
 =?us-ascii?Q?osS9UMlbJ+ynbMorB/Ktpfk62N9403PxG6dQtoD57aj3QiBkpZTj5chzih4G?=
 =?us-ascii?Q?JmQEIOmSox8ru6sNyF4wE+lNriXtue0Is7YZFADod3n+3yksenjkhWNTQInZ?=
 =?us-ascii?Q?pu+0AzCcTsPCH1KUe6iDmKJ+ZdadUk9U28y8Jmxlb7GymkPVWL1R7z79RB70?=
 =?us-ascii?Q?/6CvwSa+wo6wTP7qlOhIURUJ2OuKmX41kl649Uqv8++qqzhiNZMKbwtbne5M?=
 =?us-ascii?Q?u/jV6JQFtQBa2azzbNIelgD8zwEoBY52A8Gsbsf/W4XlTmGZ9Uwh3qtGfaXI?=
 =?us-ascii?Q?pRNi7O0jwk9twtg/pz0cmis8V92nRxQBkDIENC2tQdMPJkt1lW1HGCKYoN9v?=
 =?us-ascii?Q?lg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3CBECCF3DC8259478EE97408CD89FD02@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0190d27a-e13c-4b64-afc4-08daad25f896
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2022 14:19:42.2210
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cSNEcKDUSbOz0nNbj/Agi1DJDHUF0tQcx83TCIPmOkxIB2lYHY6yiMpEZaUNT9PMhXPhOaEH1HPzTnurw18naA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4482
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-13_08,2022-10-13_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=972 bulkscore=0
 malwarescore=0 suspectscore=0 mlxscore=0 adultscore=0 phishscore=0
 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2210130085
X-Proofpoint-ORIG-GUID: GuoPpfrZyvPFzdsWZIQQiJQ3HyxuWIlt
X-Proofpoint-GUID: GuoPpfrZyvPFzdsWZIQQiJQ3HyxuWIlt
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Oct 12, 2022, at 5:18 PM, NeilBrown <neilb@suse.de> wrote:
>=20
> On Thu, 13 Oct 2022, Chuck Lever III wrote:
>>=20
>> I think I stopped at the non-list variant of rhashtable because
>> using rhl was more complex, and the non-list variant seemed to
>> work fine. There's no architectural reason either file_hashtbl
>> or the filecache must use the non-list variant.
>>=20
>> In any event, it's worth taking the trouble now to change the
>> nfs4_file implementation proposed here as you suggest.
>=20
> If you like you could leave it as-is for now and I can provide a patch
> to convert to rhl-tables later (won't be until late October).
> There is one thing I would need to understand though: why are the
> nfsd_files per-filehandle instead of per-inode?  There is probably a
> good reason, but I cannot think of one.

I'm not clear on your offer: do you mean converting the nfsd_file
cache from rhashtable to rhl, or converting the proposed nfs4_file
rework? I had planned to do the latter myself and post a refresh.

The nfsd_file_acquire API is the only place that seems to want a
filehandle, and it's just to lookup the underlying inode. Perhaps
I don't understand your question?


--
Chuck Lever