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:     Al Viro <viro@zeniv.linux.org.uk>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Dave Chinner <david@fromorbit.com>,
        "tgraf@suug.ch" <tgraf@suug.ch>, Jeff Layton <jlayton@redhat.com>
Subject: Re: [PATCH RFC 28/30] NFSD: Set up an rhashtable for the filecache
Thread-Topic: [PATCH RFC 28/30] NFSD: Set up an rhashtable for the filecache
Thread-Index: AQHYhkLIv6uRbtoPJEu5Zs/9WvV7ta1dnH2AgAAPTACAAAaKAA==
Date:   Fri, 24 Jun 2022 00:14:53 +0000
Message-ID: <4417FB68-83C9-43DC-BB57-122D405302E7@oracle.com>
References: <165590626293.75778.9843437418112335153.stgit@manet.1015granger.net>
 <165590735022.75778.7652622979487182880.stgit@manet.1015granger.net>
 <YrTvq2ED+Xugqpyi@ZenIV> <1E65ABAA-C9D9-41F3-A93C-086381A78F10@oracle.com>
In-Reply-To: <1E65ABAA-C9D9-41F3-A93C-086381A78F10@oracle.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FEAd6IgGu8bBvUFBn4asFR2qdoUoOvGMjS1HuoQnTx1BPewKzoX+vQlhZ+tz?=
 =?us-ascii?Q?mearlS/ktoSn0nut5iVQUVVO8NFVvtkp9c454z8QPstBzXEQHpSZPQCzkXkx?=
 =?us-ascii?Q?QTUnlcHpTvZqaoViXs0xxPF1ev2uSw+gx81n8hFvFBHlqcHIwaDOlJsSWmsu?=
 =?us-ascii?Q?+mhV8EGd3LkVGwYrz8+RBY/oC+X6ufidE79rvRT9+6hPkkqa6iCewF2Bmf4D?=
 =?us-ascii?Q?X4jlYdQGbcPPHZHig19WyGZDfRQwZ2i22N92QTi0X1FnFxfv/1wf+ECojE0T?=
 =?us-ascii?Q?i1yvdOGnZRCwkYkPzVyAcaPae5gYbcTACFbaYBBPzoRHC8jQ9p/ZsD6GaGo8?=
 =?us-ascii?Q?NQq6n+8fKDaYobWO+7GzU04MU0DnQ8RWBXo9gO8T3w0MBz8nAk2btuxi6zhI?=
 =?us-ascii?Q?Cy98g+/aAisYvTlEi8N74YVhA3kge9Gxwf7MyoB2toji0rJEVU9c0ZJ17gRN?=
 =?us-ascii?Q?7l2x50bW3t+d6A0cyqcVa61fX/QlxSomuC2FahG7HXYYGkcE0UsqoccSqXKJ?=
 =?us-ascii?Q?+IqCn+HVgHPCSfX9i9KFMlYPM3YgGI8nIm7Kwfv2jsyC4X/4pyo7vGwbD5Yv?=
 =?us-ascii?Q?Phx3rQdjkH+RCrOu5ZsFuMccSCQSOMhfLUDOptinYr37YUO+D+EH6fvUuPL0?=
 =?us-ascii?Q?uTvD0IpDjoQXio9dpYVq/5e8grq9PpjpqSfvEhu17NvVXWwx1P/FonbYP5Kq?=
 =?us-ascii?Q?tZ6GjJktxrLj9gF0ZrGt+Qw2LwX76RPj69AloyYtL1Ckc7rBktvRJV3CGM9v?=
 =?us-ascii?Q?yHyRt4sISgCgmEhIrHZrqIwbMzK5zyxwfjh1WHD+oqZ7xOSKIs9xi0a1EP4T?=
 =?us-ascii?Q?vbO71wGAttLrYzYTuajnbnoB63rISTVHuxMJNMlE7RhjoSZrhY9U2w2VwUVh?=
 =?us-ascii?Q?OeJh+NTQiHgfFe9gGT5WlXZXX4WsZwRUAPxFUIEPyPFilGwljbP0gWLD0hLP?=
 =?us-ascii?Q?sVALxT2YWu+0eXO0+Wo/Y/W9NPqZetVTcXLTzPjy4OzzGR0+BC27Jy/Mr1QF?=
 =?us-ascii?Q?+tNDeJPLdSVSGvCdr21lYyriv39/Xle6Slfs87NDvQwoRGO/rEVQBTZLpY8d?=
 =?us-ascii?Q?U4o3SIYPsCgcOC5iIzodyN6VOmYTLQ7oUDJ/G8a2pPFwTYRfPXlnHFrtcIfv?=
 =?us-ascii?Q?6YzYAvDARQVnYWWAG1bp/+JboSEvd12ycbCoqZCELyHdjCPHfryUyIxoUnq/?=
 =?us-ascii?Q?DXKINE5ojnrulaj9gjfNy+XG1ykqq+AWAQp/oOZfd5zb9YoZlnwR0jxibNWK?=
 =?us-ascii?Q?kGNOTjje84woMR0QdNHTwCTGGDeicILx2RSxvVt+fEEGSgQP9Ol4fkGaoy30?=
 =?us-ascii?Q?kXUDTIPQVbiTxrtWf8PTI9QBkD17txy8tAyQvOkiN8cGCD9J0Lvv0Z7URj7L?=
 =?us-ascii?Q?sA/ik//jnG8iacGiGydV4jvToojvgzs4CB4DZqFOzPz2OP2nV/BRWrftVhk7?=
 =?us-ascii?Q?Ao0S8pSM0RlnziACKhjxZklBvlEOHKjdaLgZdDLljv+ucQmLld51PR2X1SDY?=
 =?us-ascii?Q?3THfpSgq9Fa39sSHC/2MCYIYNSxHly9gOYl4/hyyRoDCs4PAdvmfKsMXyCjj?=
 =?us-ascii?Q?Qlz4wGi9MXhjFeOU8ZkOTj7P+v63waqgZZto93qWjta6jNW6dPaCNeS7qKMH?=
 =?us-ascii?Q?6Q=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19DB34A27A128D4CB36513E1F8D78FFE@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: 8dfeb9c3-5e9e-4959-6c15-08da55768ffa
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2022 00:14:53.5933
 (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: IclFPTbxHiXxExq0WMvv9gJyXJr/EP9t16CpbC4p9kLZ93cIo203KwDPmqclzeKEYOBpFrUj5mYl/os9UBflyw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1862
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-06-23_11:2022-06-23,2022-06-23 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=844 suspectscore=0
 phishscore=0 malwarescore=0 mlxscore=0 spamscore=0 adultscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2204290000 definitions=main-2206230094
X-Proofpoint-GUID: Ft758hIK8cqUTpqEx1IVQ5W2sQO2G2zE
X-Proofpoint-ORIG-GUID: Ft758hIK8cqUTpqEx1IVQ5W2sQO2G2zE
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,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: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jun 23, 2022, at 7:51 PM, Chuck Lever III <chuck.lever@oracle.com> wro=
te:
>=20
>> On Jun 23, 2022, at 6:56 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>=20
>> On Wed, Jun 22, 2022 at 10:15:50AM -0400, Chuck Lever wrote:
>>=20
>>> +static u32 nfsd_file_obj_hashfn(const void *data, u32 len, u32 seed)
>>> +{
>>> +	const struct nfsd_file *nf =3D data;
>>> +
>>> +	return jhash2((const u32 *)&nf->nf_inode,
>>> +		      sizeof_field(struct nfsd_file, nf_inode) / sizeof(u32),
>>> +		      seed);
>>=20
>> Out of curiosity - what are you using to allocate those?  Because if
>> it's a slab, then middle bits of address (i.e. lower bits of
>> (unsigned long)data / L1_CACHE_BYTES) would better be random enough...
>=20
> 261 static struct nfsd_file *
> 262 nfsd_file_alloc(struct nfsd_file_lookup_key *key, unsigned int may)
> 263 {
> 264         static atomic_t nfsd_file_id;
> 265         struct nfsd_file *nf;
> 266=20
> 267         nf =3D kmem_cache_alloc(nfsd_file_slab, GFP_KERNEL);
>=20
> Was wondering about that. pahole says struct nfsd_file is 112
> bytes on my system.

Oops. nfsd_file_obj_hashfn() is supposed to be generating the
hash value based on the address stored in the nf_inode field.
So it's an inode pointer, alloced via kmem_cache_alloc by default.


--
Chuck Lever