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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1CA3C5472F for ; Tue, 27 Aug 2024 16:05:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A7DB6B0089; Tue, 27 Aug 2024 12:05:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5316E6B008A; Tue, 27 Aug 2024 12:05:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D2A06B0093; Tue, 27 Aug 2024 12:05:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1CBB46B0089 for ; Tue, 27 Aug 2024 12:05:28 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A5EBC81D87 for ; Tue, 27 Aug 2024 16:05:27 +0000 (UTC) X-FDA: 82498500294.25.F2EE590 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 7B62E180003 for ; Tue, 27 Aug 2024 16:05:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J0YiOHzs; spf=pass (imf16.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724774639; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UjD8rh4uYygbgmUSLYj52sXu+PdC7Tjpu6Jd1BS1Vow=; b=p/xq+HyMaMd/a7I0DQjnArzlyd2Nj6lxyZ95rFseLgoX+ImiT3pfTeV5weoiPM8BHpkqWL H4ASNV69islK4vlmSs9FSS+A/U/VGWEN6QjkcMT7pgyO3kidJxTyoBaztYVXsLhWt15Fic U0kGQWmPUh0nFMCqAD9IsdjDC05NtvQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724774639; a=rsa-sha256; cv=none; b=3TL9cjODbG6oci8iPw7YtpLvQJO7whYVwWaxwLIZtgX7THH+4yC3BNv324A4Pz8WeGz/70 CUhAM5zQYMW9VtY1Ksm5w595iB9D2l54uETXjUO3+RXCle41iKu6amG+XvFFpm/hdeqnIP uTFPMKC/QpmSMQ/tzU4p1h9N+fNTOK0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J0YiOHzs; spf=pass (imf16.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id DD4FBCE1360; Tue, 27 Aug 2024 16:05:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC8CEC581B0; Tue, 27 Aug 2024 16:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724774719; bh=s8P+tRPzYwjOiQdXkmPvI2R3fODV+CgoGK+rb+No/5E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J0YiOHzsoM5+uuZINH/Z6B4l9eSV+FmfJWkRPLp1WvIAJkETEki3y1VPfBa7sezEk 7rsMTU6/kHKeCoir9ekKsrBPb0abF7qp2TkYmGp5bL+nUqjdLo/EZk+u1c/ljv02aj 2rNqiqGejhbfTlj0nTomSOKLsDaLjmf51VQ76BbKNkIzLu/UCAR7ZCPeSc0LIQvttV Na8VLUir1DjFQvyys+f1XrrvLykaYBjIp5/cL0TbYGEkPUSyAPLq1taYiJQsBKHkYO N0nSMC05aE0otO7UqxFPcyJl8aPwgdZsk7AgeqgMl6G7x/K24+c37sUUocgq5DiGl2 AHhLDS/sJAMZg== Date: Tue, 27 Aug 2024 18:05:15 +0200 From: Christian Brauner To: Vlastimil Babka , Jens Axboe , "Paul E. McKenney" , Roman Gushchin , Jann Horn , Linus Torvalds , linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 0/3] fs,mm: add kmem_cache_create_rcu() Message-ID: <20240827-lehrjahr-bezichtigen-ecb2da63d900@brauner> References: <20240827-work-kmem_cache-rcu-v2-0-7bc9c90d5eef@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240827-work-kmem_cache-rcu-v2-0-7bc9c90d5eef@kernel.org> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7B62E180003 X-Stat-Signature: e7w8wo33iasu19ts4uyb9emcfnpq5rcf X-HE-Tag: 1724774724-382438 X-HE-Meta: U2FsdGVkX180Lmrrp9bl+hKJkF77qpQgaE81LjIgSigEoe5KY5LrgQwdvjRyL/vLk7Rv3ZE3Tay1WL6ji1VO63xmGFMENJpGxez7L1QlG+yPw3GXfVUD0uheN/0YIdkkh9EF0HWGg1nwEEfV8gdlW53IptzOfdCJL5v2d8/lsmBwvdIkTx9nadepIzmJEV+V0+zrOzYRjSef2Ji54jctaHaOjBfVIQHswUunAvreE1ACNYyVWBmbvs5XmKY//l5ItlonP5ZmIGUta8hkmypaWBifcSkU976wCs/5nPZHH+h3+3bfgiswOzgLgOhetqPNhDr4lzCDfajKsol9MhpyjlzjwzeZ+mBvDrZDzh8/oCwU3gMt0xXKVoaqM7eYsUecTGV9/VtqJZz8OJbJoxduXyLwh2/YqYKqK1xh4OJKm/R54lGjKvTO8o6d8mRwJhU4I+lOJ6wq47A9195g1XKmALQ35xaCBG7Ac5zw6dYuCAFM2n9MqJhCWpPen3TsE85+N0be0w3wHEzYAWigbGxcGCCZT3B8u63iG/rTg1igPfSv1c2M7RJVtSW0vtgSK64/L94kyiNYlzJq2bhnmTedLbn3sAFKWoS8aMCKxKNDwcUQGWkXi+BxdUoOZhi7D0E9CW82uXZTjL8MrYXM5XjsDDDPLF4tOj6JqYq9X12qBVJb+HMSAetXrs3cXhigT4THk+7ZWSJcofk09C78K4x4lVnXSY6BjgdyyGG61eqwRWu1u8zuK7YpQXHSuv9JAHVjrcNqSlB2P/7a/h0wNYMwXXpG+EajGK6Ke6w325k/RTZkG4uoIxmYBnD6khjwj5Tlj5dSWPp5yyRwK/x7T/L/DRcY4lZscO6DzwtsgmdWy75kqQmbi4f9dBGcKYYJgyIZXXD9u84Xx6N8viZACj4NeMoWDr5Z4MFI2joThV9Mwh+N34lJcEd37bw55Uao3dcYJldcdG0UynOjfUj5/35 SchPsLzT z9XCFxI/BO1C5HE5y7/+JzqEXROfAB9pfhRMG53xSGFNeFNh6E2IPhcPZtDBhk63G2XT0XPtQ9khEQK9XFOHv8QEsvHnrf5nEKUFQPLwNM2wRR108JMB3/AWyenfOIfsB2atlt2tEDwPO/4IUJQBghytVr9HhUIISrAYvhfkZKMX0PF6NWZhCtI8buCgng9Rh/oHSWhFdnuDqXpSUQVgm8gNM9gPHd3ySEFu2sh5HLV2fEE/SPaJLiyfH5c/6fCBCJ1ZqzOPIeSVGYfFu7qza3ynpsQbC6Gign5hn1Ibf7XnNrk7sshgb8gmiUQvoNLtYcNBhBCDLOiirSXU5xa8BPZquRQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Aug 27, 2024 at 05:59:41PM GMT, Christian Brauner wrote: > When a kmem cache is created with SLAB_TYPESAFE_BY_RCU the free pointer > must be located outside of the object because we don't know what part of > the memory can safely be overwritten as it may be needed to prevent > object recycling. > > That has the consequence that SLAB_TYPESAFE_BY_RCU may end up adding a > new cacheline. This is the case for .e.g, struct file. After having it > shrunk down by 40 bytes and having it fit in three cachelines we still > have SLAB_TYPESAFE_BY_RCU adding a fourth cacheline because it needs to > accomodate the free pointer and is hardware cacheline aligned. > > I tried to find ways to rectify this as struct file is pretty much > everywhere and having it use less memory is a good thing. So here's a > proposal. > > I was hoping to get something to this effect into v6.12. > > If we really want to switch to a struct to pass kmem_cache parameters I > can do the preparatory patch to convert all kmem_cache_create() and > kmem_cache_create_usercopy() callers to use a struct for initialization > of course. I can do this as a preparatory work or as follow-up work to > this series. Thoughts? So one thing I can do is to add: struct kmem_cache_args { .freeptr_offset, .useroffset, .flags, .name, }; accompanied by: int kmem_create_cache(struct kmem_cache_args *args); and then switch both the filp cache and Jens' io_kiocb cache over to use these two helpers. Then we can convert other callers one by one. @Vlastimil, @Jens, @Linus what do you think?