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 D8416C52D7F for ; Thu, 15 Aug 2024 19:08:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65D9A6B019D; Thu, 15 Aug 2024 15:08:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60DC06B019E; Thu, 15 Aug 2024 15:08:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D5D76B019F; Thu, 15 Aug 2024 15:08:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 279E96B019D for ; Thu, 15 Aug 2024 15:08:12 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 98FEAA8391 for ; Thu, 15 Aug 2024 19:08:11 +0000 (UTC) X-FDA: 82455415182.23.FDCB049 Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by imf16.hostedemail.com (Postfix) with ESMTP id C008718001E for ; Thu, 15 Aug 2024 19:08:09 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=dtdNWwRY; spf=pass (imf16.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723748853; a=rsa-sha256; cv=none; b=re9mH66zxUuSPPnPX8D3ylwPZaZZje12i1oU6RopOFGXx0Vg+K3KXUszNZDluX4JwUKMJ+ vQkUFffcXMpm8oOKJUev07JeAhvgaP34NghlbG5ygEQuK38OQkkjatdiLWQ03t/LttNWq3 J3MWRtXtE51s0LoYJIr1Dffcbfv2ldw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=dtdNWwRY; spf=pass (imf16.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.43.16 as permitted sender) smtp.mailfrom=benno.lossin@proton.me; dmarc=pass (policy=quarantine) header.from=proton.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723748853; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0ozggr77TSIkab1vrhgR73woDMghC/BCCc6vgLBxdr0=; b=fdt5BagXR94lIqgbnlSsAiyMh27O/oQ10wPJJJRQ9KmzEqDbAziLQ1kN8oc1Z0lTp/VTxi VdXznYwp7x5UHtVIHdwdWX674gYuB+n+zoKn25AO9RmTaJ6D2M3Z/UzRWxCCBs09W14GP6 ZYbk3KkyEoLQYIicXjqmjQKG5Bhp2hE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1723748887; x=1724008087; bh=0ozggr77TSIkab1vrhgR73woDMghC/BCCc6vgLBxdr0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=dtdNWwRYXesRJQkZUlaNUCVEPKgakblWm1jHWX0cJLCJP8Pd7uzUZ3prpdRAED0Zy f/2WaNfMPp4/WTYtRtsJ9RmHHjJayky8Jpthcn4rYkE9hvRcA2MRxSeIUHPG05lOSu mdjtKAEgBfRVl6BEu2/6YuNUb6SvkNdysF6gYUCMQkYlooWzpK9nttRWUU20Rf4cTj CFVm/Vh9enF1j66a/lAuahAY3z8FHO8ozaGOzL7cvYqzrpMCOeQZFN9Io81gY91prq qXCT5wXDqWnc9AXbQVFWLAULnJVTlhqg66Mww1rygp9MERXZwt0FHhH3XHCUS2gHNb x1RWnilrdwRkg== Date: Thu, 15 Aug 2024 19:08:02 +0000 To: Danilo Krummrich From: Benno Lossin Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@samsung.com, aliceryhl@google.com, akpm@linux-foundation.org, daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v5 06/26] rust: alloc: implement `Vmalloc` allocator Message-ID: In-Reply-To: References: <20240812182355.11641-1-dakr@kernel.org> <20240812182355.11641-7-dakr@kernel.org> <5dfe8bae-2c1e-47d4-9fb4-373b7d714c4f@proton.me> <01a46c6d-0107-4455-8c87-af43426752ff@proton.me> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 52564aee61cdea9f9328fff33fb3ea771ee2a636 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: nnmkoe5899sbf8xmjz668gczshdesd11 X-Rspamd-Queue-Id: C008718001E X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1723748889-78711 X-HE-Meta: U2FsdGVkX19HnveMxWwSsuOucgfq5eMmLF3PD0xCCvMz50PzoRETdkH7HW2f3PX3Vx+Giq1zRUrecmVxa7FnUeUkkXsEFkL62qB3vKq0NWQuVFG6r8cKI3p1UmiHhnxFwwuZmd1gZZWPhppi7crIvJtNQYFVBy79pfx5/dLN2FnSc8lqbH2cRFJZ6kugcvnQQZ0d5hW+oZ7LKOMt3vNfXE2F3wAxo6yd7vTYAhgJNnn16o60oHJuJswMOmcYgIFTuvekOOYn27WXZ9Oz2uBm2Kmh1+NoKGvBRlzjdc0D0Pg1SEqld7eRXXlWVP95XIBe81gA0XyyNU5DeJ4C+EanZdTg/eSiaUgCBbqrhb0y8cxKzchB2dmd3K/DSceTjUUch9HkdykW1oH4yc/fc0SYnC260oZvNAcn6FhNdtI4qhVRF4A2BM54ocHkObbNZW7gKXEZT0HT0QeXYmfWrLSuRShFNtHOJX3d1lS4aPe+yPgBVHrot2sGaWDHa5Yhbp5axfmktbGkjST472YTlSUc7c2klFaFebuA2oA+MDgmGu0ZJGQYagVqnHxyjrsuJCiNiP9KbWTiKWTMlnRv7VB8BGTWfVRPuMRYbUdFu4k7OKVeiGv7YJrrNfm9gc8aDk+SKw2rd0gCspk0NfZLS8n8gaES+uyL+7LeExspF8uiCCkUMdlt8KcUetwwmPvhpBSb2Cm1/P8WjlNfvRCP95DXlKGnbYagJ0FoeLbqGSL5FBGP+VjHHPekpBo55gfQqeY07LrHC+SRB290BZoQZPF8ZikZusmBM5nwgWqoq9Fmj0JCxkFxWUsbLt5lAYvCN3uYGWFN1+/oNiTR0woWsBK3kdbGCKAL9f6G7SHKbITlV1zwAIJnjM/VweiEbE8pOL/xEwS4bztMunx56u4/m4IgFTEvxRXzm6kbZBXBu9xgq43ORzSxYzEFqFuTfLPeuN4wkgQET9kiDuUG9Zu2ZCD t51ypAwV eBKxre/+qHltuaXbdsFI7gdKDUtAHbwnqHsQnpElLvYhPIm3167oBveOQk8cdyKakfrOG7s6g4KJqb6zkpql4oQSCctTsPzWFYrBgZYUzJqF6m86coBdWGZmlAxqVhVusb48MsgKetoW9rlFZLfTSHehyWrI0uyqlJuY3uwdSv0/PqqI905744LdaNGasYPldqT5pchmZIEIQfIyGZlSm8dPKgiT932iTAu4Aul9rr3Nqn/+XWZExU8qUVbXuFR3ual85jHH8VTvu3H523Rpk6oMqj0n8JFNn+7/noCJwVEBSbIOk+T/s84gkMnpLZ06qv4FJn1fLALQi0gWVtCfEgfnj69TVUUpy+rSOSaPj0z3bt9GJkXlmktFaVgrvTpOwgGM0UZ0TGChTKNgrQrFSmWggR+ShMFB4lG8/7ZZFcDvWxyU= 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 15.08.24 16:23, Danilo Krummrich wrote: > On Thu, Aug 15, 2024 at 01:44:27PM +0000, Benno Lossin wrote: >> On 15.08.24 14:29, Danilo Krummrich wrote: >>> On Thu, Aug 15, 2024 at 06:48:19AM +0000, Benno Lossin wrote: >>>> On 15.08.24 01:20, Danilo Krummrich wrote: >>>>> On Thu, Aug 15, 2024 at 12:13:06AM +0200, Danilo Krummrich wrote: >>>>>>> How difficult will it be to support this? (it is a weird requiremen= t, >>>>>>> but I dislike just returning an error...) >>>>>> >>>>>> It's not difficult to support at all. But it requires a C API taking= an >>>>>> alignment argument (same for `KVmalloc`). >>>> >>>> I see, that's good to know. >>>> >>>>>> Coming up with a vrealloc_aligned() is rather trivial. kvrealloc_ali= gned() would >>>>>> be a bit weird though, because the alignment argument could only be = really >>>>>> honored if we run into the vrealloc() case. For the krealloc() case = it'd still >>>>>> depend on the bucket size that is selected for the requested size. >>>> >>>> Yeah... Maybe some more logic on the Rust side can help with that. >>> >>> Only if we reimplement `KVmalloc` in Rust, However, there are quite som= e special >>> cases in __kvmalloc_node_noprof(), i.e. fixup page flags, sanity check = the size >>> on kmalloc failure, fail on certain page flags, etc. >>> >>> I don't really want to duplicate this code, unless we absolutely have t= o. >> >> I am under the (probably wrong) impression that kvmalloc has some size >> check and selects vmalloc or kmalloc depending on that. >=20 > Basically, yes. But as mentioned above, there are quite some corner cases= [1]. >=20 >> I think that we >> could check the size and if it is going to allocate via kmalloc, then we >> adjust the size for alignment as usual >=20 > We don't need this adjustment any longer, see commit ad59baa31695 ("slab,= rust: > extend kmalloc() alignment guarantees to remove Rust padding"). >=20 >> and if it is going to select >> vmalloc, then we can just pass the alignment (if the vmalloc alignment >> patch is done first). >=20 > Yeah, but as mentioned, I'd prefer to do this in C, such that we don't ne= ed to > open code everything the C code already does. >=20 > [1] https://elixir.bootlin.com/linux/v6.11-rc3/source/mm/util.c#L628 I see, then it's probably better to just add an align parameter variant on the C side. Instead of rebuilding it in Rust. --- Cheers, Benno