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 3CCBFC3DA7F for ; Mon, 5 Aug 2024 00:54:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 623AC6B007B; Sun, 4 Aug 2024 20:54:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D3506B0082; Sun, 4 Aug 2024 20:54:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C1C26B0085; Sun, 4 Aug 2024 20:54:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3001C6B007B for ; Sun, 4 Aug 2024 20:54:56 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A2858A1B44 for ; Mon, 5 Aug 2024 00:54:55 +0000 (UTC) X-FDA: 82416372150.24.E1940AD Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf05.hostedemail.com (Postfix) with ESMTP id 612FF100011 for ; Mon, 5 Aug 2024 00:54:53 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hzJtC9vD; spf=pass (imf05.hostedemail.com: domain of dakr@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722819234; 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=LgiKvoFUNR+qOfrHWk1z/iWhd1BRv1qEseFwjtJKUcw=; b=Bv4kYKo1JnJeW/4ewFEICSUJBzNx+SdYePE3CedmxF9/0uPCEs90mp0vYa14KSMYXABIQt zfaCCW7VkPWvoELPqizrPIVXrFH4+P+AmzR1FVepfK7xjIkabvJIO5LVwHBhwAHERP9qUL cfSqI/iNVkOzI1X/oWvQh4qjanl6CSI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722819234; a=rsa-sha256; cv=none; b=ezr4wolYbUUsnifSmLgelskDubpR9KFwzJsUkwefDq9zWq11c+JwCO7HiZFZl90TofnspN AYH91gQn83aViDhhdURtkNO3Vmr7A5cPSirKQ9JN3WqlWqWWHUebF+ZmYP/DgLtGroU/k0 3zUXd5biWpzNuCQf3DnXQAnw/2gUZ80= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=hzJtC9vD; spf=pass (imf05.hostedemail.com: domain of dakr@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=none) 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 429FBCE0A38; Mon, 5 Aug 2024 00:54:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 766A0C32786; Mon, 5 Aug 2024 00:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722819289; bh=9jk2LYQQJtrrk9iFLGskRmEKMBMgClztVJRPefwAmBs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hzJtC9vDe3UycGbXmq2kHn5+HfEHfbt21tX8GZa2cL3lpvcBQdGFwRiM+OuD50Gmr uJguh9TBLT9YLVkcNl6196X+lmGsUPCSd3MSd84VsYVO1WRORxZkOSiF9Mjhi5iDbC 1bPYB4MAYgrxCqJDeYFDvHLnH5EC0wVX61pL+81L7lrRIyPP0xFT9b0pSA/wv9FzxP JANRWKawWD7kHj4kdFI98y6OyVHtSDq03KkBrY6hlyPxFVKlqlhm22t8/jYYI6kN58 EQhPwfHuEeuXfeDRRLYEOe1o4LEwfO1IciDqLRY8mcYVtOsnWQyYIEWTqrMx1cP4re 4QZszt7BJPanw== Date: Mon, 5 Aug 2024 02:54:41 +0200 From: Danilo Krummrich To: Boqun Feng Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, 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, acurrid@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, Vlastimil Babka Subject: Re: [PATCH v3 06/25] rust: alloc: implement `Vmalloc` allocator Message-ID: References: <20240801000641.1882-1-dakr@kernel.org> <20240801000641.1882-7-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 612FF100011 X-Stat-Signature: ya4jjbsx8eu57sx6kw957n47ckq8ksak X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1722819292-407269 X-HE-Meta: U2FsdGVkX1+DQs1vca+/oyoFJRtUa30nZXDgkeeS700OQNlC2pXmPd5N+Qox7yuS4oCRsSt/yIpXSqP1a+5z9UDJWg0S9LqJVBeLwHAchPtIjyozVWVtXpuTIQTWOWg/MAuv9SXdQFeUa/SdTbs/orjDxot/B23KUuCKCra5FfvE2CRVdZXGwTxnR901tD2gOghyVHVCaH7/Qg9O6MNdS3WtaPR6w6XkkiErRA4JBX8LMKviXEiznob49g1+bHzuxLq+7h5g7I44sgWC4VTQZ4jdAKtnEGTbup/oEmIZbVpp6MawiThIBb5C+DD/5vq06McwywUEZaZlTeZMTpwA/LA5XgznAI4VwX+jGIaJDP1vfIE4OkuxKR9goeIZycyaGn8XBa8uXNLWI1i30Vd87hz9usI8i39QEB7j/jrv1BFQjFX6yu2ttTKrURBRQr1RfHCLLkX5waKQHJVJPy8FmOnD4/Fwli9XkVd/rUkUVoef4gcs3JOYeZ2h36Bscx102D6xEu2dkTx5xlMVPjuS16mIPuNqNyztkpPWnFwIOi/M7hnLb+ibT95/ki1+GTXBdqs5yytyzTS2gvRZCXDUYpYM0BJUHP6g8Hn4NAlr23qYEDJk+aF7pbJrWJ5PNAdxKPs8bgHeCaSLwo1HkTTPI23Y5tDElHIZbdVwLLhBrIgGahK8HyYEUGSVQz5fhEM6sUmVqDSryHWg2eyPDOVLl85Rio7d0enX8wO4EW4iiRvcoJ7QoJyOXgQJsJiFQwaV6jOLZZfBFryrkxa8CED5pGsMdQbnlZ4rIA34sFUmzELWWbaBRRfGwNj0a0L8vYEAVme3NHH/BPQOyfE+4+R6jhMwRa+i71ZtCoxQTC2ity48rjBTy8FuHicn9qU98yYlF2fXj3wNfI5thp5g5RfOT/c7mA4+8mknZLgXLz4VJX6BEymcBHNa6gzUpGOSzJLN2HzsUiinlqESsuYTPD9 mOf17l6+ zjMwWEtwpfd5OI7KaHyDF93+1SNhyT3+WzhwxbM1ZjWvdmfNqsutFNfYYCYRgIxCDXxJ5AxjBlnDzsbwonRg0aWKcX1uwR69h3tMU4MVQVfHltNuLSJDtiSHIkhHT791AJNW+e0D4Tw22GkiM/XMUuv6nORFwgjjwRDjP54CEYohs0opR+ZaJXy9REArFOXm3/NMFaRhfO6tyYAkvi6boIvF/Yw0GCsAVKV0kcOlXnZUUzAiTVCyXHPR5t4oaDBzESsxBaoPY1RuyMNq/omCwDV3yG7hrOM1CYTI7 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 Sun, Aug 04, 2024 at 04:57:30PM -0700, Boqun Feng wrote: > On Sun, Aug 04, 2024 at 07:39:52PM +0200, Danilo Krummrich wrote: > [...] > > > > > > +unsafe impl Allocator for Vmalloc { > > > > > > + unsafe fn realloc( > > > > > > + ptr: Option>, > > > > > > + layout: Layout, > > > > > > + flags: Flags, > > > > > > + ) -> Result, AllocError> { > > > > > > + let realloc = ReallocFunc::vrealloc(); > > > > > > + > > > > > > > > > > IIUC, vrealloc() calls __vmalloc_noprof() in allocation case, that is > > > > > calling __vmalloc_node_noprof() with align=1. In such a case, how would > > > > > vmalloc() guarantee the allocated memory is aligned to layout.align()? > > > > > > > > True, good catch. I thought of this a while ago and then forgot to fix it. > > > > > > Just for clarification, we're always PAGE_SIZE aligned (guaranteed by > > > __alloc_vmap_area()), which probably would always be sufficient. That's why I > > > didn't gave it too much attention in the first place and then forgot about it. > > > > > > However, we indeed do not honor layout.align() if it's larger than PAGE_SIZE. > > > > Another note on that: > > > > My plan for this series was to just fail allocation for alignment requests > > larger than PAGE_SIZE. And, if required, address larger alignments in a later > > Yeah, this sounds reasonable. > > > series, since this one is probably big enough already. > > > > However, for `Vmalloc` we could support it right away, since it's trivial. For > > `KVmalloc` though it requires a bit more effort. > > > > Could you elaborate why it requires a bit more effort? Because > kvrealloc() and kvmalloc() in C don't have a way to specify alignment > requirement? Yes, exactly that. > If so, I think a solution to that would be just providing > the K-or-V switch in Rust code, i.e. just `Vmalloc` and `Kmalloc` to > implement `KVmalloc`, which I don't think is a bad idea. I really think we should do it in C. Look at all the special cases is __kvmalloc_node_noprof(): fixup page flags, sanity check the size on kmalloc failure, fail on certain page flags, etc. I think we really want to keep all this logic in a single place and not replicate it on the Rust side. > > Regards, > Boqun > > > For consistancy it would probably be better to support alignments larger than > > PAGE_SIZE either for `Vmalloc` and `KVmalloc` or neither of those though. > > > > My personal tendency goes a bit more into the direction of picking consistancy. > > > > Any other opinions? > > > [...] >