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 E2C47C3DA7F for ; Thu, 15 Aug 2024 06:48:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56F106B007B; Thu, 15 Aug 2024 02:48:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F85A6B0082; Thu, 15 Aug 2024 02:48:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 398B36B0083; Thu, 15 Aug 2024 02:48:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 183776B007B for ; Thu, 15 Aug 2024 02:48:34 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8F04F16134D for ; Thu, 15 Aug 2024 06:48:33 +0000 (UTC) X-FDA: 82453551306.17.D9E179C Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by imf15.hostedemail.com (Postfix) with ESMTP id A09B0A001A for ; Thu, 15 Aug 2024 06:48:31 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=W+dE1+u1; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (imf15.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.40.133 as permitted sender) smtp.mailfrom=benno.lossin@proton.me ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723704452; a=rsa-sha256; cv=none; b=G0zpjF/AfOsEsy3OiJTPCgWYtW7jqabguLTFPhz30aEUfD+j3pFukCiWbrsZilAfLkCpWC p0IioYtmAhLddg2bG0HG87mBqaS/rPqZhlmA5wo58uvrbuqDwXiFOL95LY3vdMwpgfzX7C fofmfpXxLHLK0p5imLAQm/g7eeQhyzs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=proton.me header.s=protonmail header.b=W+dE1+u1; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (imf15.hostedemail.com: domain of benno.lossin@proton.me designates 185.70.40.133 as permitted sender) smtp.mailfrom=benno.lossin@proton.me ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723704452; 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=5I4uF48/D5iv+622qy+0xU6rTasLnm4ofO5ZVU8Faa0=; b=HQfGNISLkwlgKDrXolT/AZiNtl8014yDLAd/svE18R/MrrqwNhSLD7i35OpdjFib9p+ozc bHHByTXqw/moTfZFCUkNsx6IbHuatT6m5s/vFC7dO2PmsEGvurJ3zPFo51P34d8wiS93og iB6U7Xgu9F1SM2vA9GGV2KlJp0kpaGc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1723704508; x=1723963708; bh=5I4uF48/D5iv+622qy+0xU6rTasLnm4ofO5ZVU8Faa0=; 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=W+dE1+u19fQ8vRibOHcKr1+/M5xi0Qu9fn4/aAdgRuLu2q2vDQMtjFuZ9NpkM++N2 G77L82ThfRUOnNo4JFkYH15EINEmEQRKz+DEJ8EsfOFHQVJQUEHHAm5J4uqC1/sIr7 ctQ4KcLFJ0kNXaZzoFba94wUqa8tAPPL2PqP33iHWq1d4cyGa/dl8UfngJXH3fDxiI 4MuwDIa87zbydoAvTQ07vrF5/IUydQKPzKyQpgrkUQiy0FD2UmRIMbjySk4WWs7eJY vT+RATNBIvosrqPtmZo0rXAP+hq9cd4L728GKULHaV0FTDcsxT+jOSCBIxtvzNxPhF pHMnPgs5l1uIw== Date: Thu, 15 Aug 2024 06:48:19 +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: <5dfe8bae-2c1e-47d4-9fb4-373b7d714c4f@proton.me> In-Reply-To: References: <20240812182355.11641-1-dakr@kernel.org> <20240812182355.11641-7-dakr@kernel.org> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 7dce0f614b91ef9b8e959229288c0aba3f8bbc85 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A09B0A001A X-Stat-Signature: krfuzegi6iz1ckoqbkh9g3cd83bewbfb X-Rspam-User: X-HE-Tag: 1723704511-793145 X-HE-Meta: U2FsdGVkX19mHHLp/u973ftVnCRYSv1LJAqmIkaYK2n7svpR6HC35PqyRFG9tQ67pH0SHmAPmV9MdGBjl9ks+54LcT+n1v6yvW+4ddQCCZsFtZPqnkwq0XQbhFV7OXXv42LszGQ0TNIC8x9ZuxtHnMlVUW61YBB9L7xaWuRyhGw9ZaOr/ptmnirSanA6u7UaBEcrM2+GqfpJdAJ0f0qNLHRFP6bWhApIuXTPAHAyZen1Qy78IA1lkhDiglbyWnscY/ZwMrc3G1V28VM7vafkbgQe6zZxe6TKqFps5vGsoO7G6FYtC3NIYpQVunH5X7tMNE0mqV237N0RVeaMq1kmXhzKKcW/NzUXbL5U8mg2Haol7wIKfFuPxvfj6DZ+ZDH02/4hqj7IxVKJbfIfNlrfG77tMUWFUq+tclacYtf1JjYA/keXM60OuviQgjYoxMlWjUMfiD58Lf5OPdVIRihS1Zu6oFpcgjQ6hMVIzI0V1ao1hyu/PJLKJo8vjgsZPIXSx04r7UQlkHTjA+BiLRM0a936gYse+rMbuWSx65hwAoojJNdNAtI1EsjmdYA+PX805yFuZyz9hUeqN3wVE5JO9WS7NsTR2gYEqCuBtAgg0Yf7Tqprt6YU5efPMO1Vkr1LoUsjdPkDIVb5w7sb3Tt+u9gKis3OC+fnkNZVygiUdaoZ+imBsGeOurvkvvqBz9l/bNDjvU8H1vS2Lvd0ERwlZ2svsF3YPuTblVjL4tn5OL27W5yAAU7qX/1/MxcwJJMc9wax76a5vwR/HfMx/0ChBobQz/k0cuKJ280dPxxF6pA8ZZ3sJbnBZE2TqCZ5yv+veFf4wlJ96iZFMS5pOfvtb5/wEkz0UV7gjzVpKcqiW7EP/ldDsQxzWumSVGjgWCThGIKZ8p2IX8o4fmr2ViJh4ZhTMJxcMPp5VTDmFuYklLTTMNGEL6M26pnxV9b3eF4BG/Bebntep0CWQQZMNAN dHj3hueF dAxhSdT9UlxR4ffhrqz83aNlMGhWFkLEFTwb25M8zr325UnmdKXwaTLMfN5k2a1OLjZMIeZWctmRQQS2PuNPWflYoxXplWU5uqXnXxMCNU791C5y0PMmllgX41UasREE7vTOPoMOlGeSxKQTXNjOPUNtTV8dkbDtxrifvYKwvjZjNFBdgzPFvb380aSuOlRxfeP8BhUU7b9UsGknPMWeviBNbHcmfkpbfb3fi1s4wM2ROmIWeQHjnxzcAy6Q2TaSYZd2aOz9WTyvW4621pWu0pS9IJDQ/ec3ursULYZdhu8Sj8yXkYFnrlm+B6YdjBAXBqYtLlcf6bDsYeXHwylNiZXhZLfUq2fHm/GiA/Ygp//SFGmY= 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 01:20, Danilo Krummrich wrote: > On Thu, Aug 15, 2024 at 12:13:06AM +0200, Danilo Krummrich wrote: >> >>> >>>> + ptr: Option>, >>>> + layout: Layout, >>>> + flags: Flags, >>>> + ) -> Result, AllocError> { >>>> + // TODO: Support alignments larger than PAGE_SIZE. >>>> + if layout.align() > bindings::PAGE_SIZE { >>>> + pr_warn!("Vmalloc does not support alignments larger than= PAGE_SIZE yet.\n"); >>>> + return Err(AllocError); >>> >>> I think here we should first try to use `build_error!`, most often the >>> alignment will be specified statically, so it should get optimized away= . >> >> Sure, we can try that first. >=20 > I think I spoke too soon here. I don't think `build_error!` or `build_ass= ert!` > can work here, it would also fail the build when the compiler doesn't kno= w the > value of the alignment, wouldn't it? I remember that I wasn't overly happ= y about > failing this on runtime either when I first thought about this case, but = I also > couldn't think of something better. Yes, it might fail even though the alignment at runtime will be fine. But that's why I suggested trying `build_error!`(or `build_assert!`) first, if nobody hits the case where the compiler cannot figure it out, then we can keep it. If there are instances, where it fails, but the alignment would be fine at runtime, then we can change it to the above. (I would add such a comment above the assert). > In the end it's rather unlikely to ever hit this case, and probably even = more > unlikely to hit it for a sane reason. Yeah, but I still prefer the build to fail, rather than emitting a warn message that can be overlooked at runtime. >>> How difficult will it be to support this? (it is a weird requirement, >>> 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_aligned= () would >> be a bit weird though, because the alignment argument could only be real= ly >> 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. >> Adding the C API, I'm also pretty sure someone's gonna ask what we need = an >> alignment larger than PAGE_SIZE for and if we have a real use case for t= hat. >> I'm not entirely sure we have a reasonable answer for that. We could argue that we can remove an "ugly hack" (when we don't have the build assert, if we do have that, I don't mind not supporting it), but I agree that finding a user will be difficult. >> I got some hacked up patches for that, but I'd rather polish and send th= em once >> we actually need it. Sure, just wanted to check why you don't want to do it this series. --- Cheers, Benno