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 DFF6EC3DA4A for ; Thu, 1 Aug 2024 15:37:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C2E26B0099; Thu, 1 Aug 2024 11:37:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74B746B009A; Thu, 1 Aug 2024 11:37:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC066B009B; Thu, 1 Aug 2024 11:37:48 -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 3A5AA6B0099 for ; Thu, 1 Aug 2024 11:37:48 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id E12FFA0E85 for ; Thu, 1 Aug 2024 15:37:47 +0000 (UTC) X-FDA: 82404081774.16.7736520 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf29.hostedemail.com (Postfix) with ESMTP id 9599712001D for ; Thu, 1 Aug 2024 15:37:45 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m2g7XPaS; spf=pass (imf29.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=1722526621; 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=zLg83CnKr0foen3ULV+uOXR+x1cy5AALR+x0O33WraM=; b=QaL3zEacluIcGr2rPyyKQZLa4UvGCsMR8Ta5drQcTqUiyLgFT/qe3jB1NvSYxYbDzl76wJ 3+0yMtGTxBIabO21fItGCFrWtN9cwNKQ9s55xronj5vRFEOHyZKec1EAIeagTasUjkH9DK 72atrbtDK0DDai6gMvtL+5YaPr0s4Lg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=m2g7XPaS; spf=pass (imf29.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722526621; a=rsa-sha256; cv=none; b=tV1hsytlPn1pzbT1FDcn6nObB3FP9krsSYPjSqzjmGnEzeusCHBcF9Jhi6nhQdSX62B4Wg /h9s4M0KeEcO7+pmiCH2wKB1HPjw/aSzZjWwdNf+UEQoGgFvaaZlfqRACZq5L5EICaj6nS KECK+VB5c3qsZRHOMWMEpyr2P80Fczg= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 928D4CE1294; Thu, 1 Aug 2024 15:37:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC277C32786; Thu, 1 Aug 2024 15:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722526660; bh=eVLalnnIMUfT3DQM+7CU8nlT5DrlvzT2NV18fgmDEnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m2g7XPaSWegFc9Wbo2iye2lo+3VGPXt+ax9u/+NNrxtCic7cXtfZcLQm+MkcL5gAU 5pIfNlOf9AH22KT7r2GVRetDNNvMMw2rfI5RrCQuc74edkz1FoYGSZmlx3d0+vNIHm 7vDwYhDUt9wSJCkwE9ikljdM86BEKT/zB+ZUETT37D4xl3fo2pfOfWlN/H9wkDZPvU n10TXL4GCZCvMZ/4MHLTJnKy/JRSmCqunR1hDjxlzIug0TaNdiydAOj1LjmE2lnLwP H5d57AXKlX58UG20Ub3Cpfkna0nz7ktXNKX9yekaQJhDhyxYhzCerWiv3DMh9CEL6X UXrWwTC49DQKA== Date: Thu, 1 Aug 2024 17:37:33 +0200 From: Danilo Krummrich To: Alice Ryhl Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, benno.lossin@proton.me, a.hindborg@samsung.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 Subject: Re: [PATCH v3 17/25] rust: alloc: implement `collect` for `IntoIter` Message-ID: References: <20240801000641.1882-1-dakr@kernel.org> <20240801000641.1882-18-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: g5r8kfy7tt4raqgpz4hmmfwmc4eporor X-Rspam-User: X-Rspamd-Queue-Id: 9599712001D X-Rspamd-Server: rspam02 X-HE-Tag: 1722526665-683543 X-HE-Meta: U2FsdGVkX19vO8koYsdKwwO4HOuzseAzetFeaMfJ6HSdKG9L5PdN0XuplhTdnRFkZMHXN+0p7Ve6FhlWEndXiAdLv2qhuzOKlMzW3qut80ZlpCRektToF2IYZ44K8hf05OjmoF455VS29jglrsCJ4RDF1g5B6tS2bRhOsBVsU+siMeoJvdiqGbCEhC0XbFENyYq2/Ebk3n2Jo4hMBpkJe/gR0BHLL/IKJxUMpz7kE6+PByHZx+C+/ReWwtBAS+pdQiATr453X4vlXbs09K826aImapq71b7Q9piDT88bJWJ6Q60NxrI2vkSXZm4c6Z7syLiKB5bVscMJyI88Za19bqYlLEXVaC4GpLZtkGUAf8wmdM8az0evJr2nSXGi26TRYAL0litafuX97mVClxcYuz2hdf240VvdxLvvT3ejyT/J+aDsgLQwzaRddHf0l96iJym3KNRczQpMZvrD3iCCvpY5RPMBWohRVZXYz45JoX+8Y8OPjyqxDB4wJhXaZ/cPaFDkLzqYg9pPIPTin8Ik2QP39qg4q3H0dJgdU1kA15CgH6R2Gyjphwol/qtMOrSPkYNaCl+30dreI4vS0PL6GLr9rPop6waVjNgA6WDeGh3k6ctCULE5FD7ewdoOy/xZPbhhjGPKH9bAAIqJ7ew9PWwFZ7rbgW1Tv0dwiL/CcGh73QYsVjjONi65xPcbYjC3g0qreXsZFTFU3/Kbla+5cNyYhKg9zkm3D2vIwZkqOUA5E19AZr4GQ8jBLf38o43UFE+rmUh8n3+f0msDAGdsqPt4WLDz6eyaxZQbSZv2GYMRte694o/43/lwVQXhLkkLQKtjm3xcps3l7dcIyyMI/N5wboBMRyebuFDwrYyq3evzltYt3rn7dzaWopEO6yY5m0DybSgkathWTF8wTHm7fh8UEFqWm2mOIwDm+d7gS5EfPP8TebSYYUybFOg7zL5yAzODbm2l4Feb35RO3Hp wMyvZEEa ZKaqb4wFIkN6P+90EnNr+HVet1jfZbkOUQFbEsUUjCjToNlP3YjUgXOO11hte58Ru1P77Ory/72zhEwvVDzd108MsEoO6PWksBp82f94XLxJ29N91mZvu62jkmX9MlasGpjLAPZZvGKWERQul1HwdpTm8ADMcuoUhB1mgT/uKCBth0nuCf4t/okwbj4mvJO4jmUhCdzj4UPare2dQOUYF31mhKzaFox0ujVg7+KLecTf37xV9271UMOoOsJd7g/MgJwKh++4Rjmqs6yGoBdarwMIDKqUq1DNtM9HSIUwVmLWVxsRXPce5XMe0ErOs5wkqNMGAPX9bQJFFg1GB+Cxc8+dHkeCxHMrjedhI+CUnTODMuGJRGpxA5kpoJQ== 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 Thu, Aug 01, 2024 at 05:10:22PM +0200, Alice Ryhl wrote: > On Thu, Aug 1, 2024 at 2:08 AM Danilo Krummrich wrote: > > > > Currently, we can't implement `FromIterator`. There are a couple of > > issues with this trait in the kernel, namely: > > > > - Rust's specialization feature is unstable. This prevents us to > > optimze for the special case where `I::IntoIter` equals `Vec`'s > > `IntoIter` type. > > - We also can't use `I::IntoIter`'s type ID either to work around this, > > since `FromIterator` doesn't require this type to be `'static`. > > - `FromIterator::from_iter` does return `Self` instead of > > `Result`, hence we can't properly handle allocation > > failures. > > - Neither `Iterator::collect` nor `FromIterator::from_iter` can handle > > additional allocation flags. > > > > Instead, provide `IntoIter::collect`, such that we can at least convert > > `IntoIter` into a `Vec` again. > > > > Signed-off-by: Danilo Krummrich > > I'm not convinced a collect implementation specific to IntoIter is necessary? For the reasons above, we can't implement `FromIterator`. At some point we may want to implement our own kernel `FromIterator` trait, but that's out of scope for this series. For now, I just want to provide a way to get a `Vec` from `IntoIter` again, which without `Vec::collect` would be impossible. > > > + > > + // SAFETY: `buf` points to the start of the backing buffer and `len` is guaranteed to be > > + // smaller than `cap`. Depending on `alloc` this operation may shrink the buffer or leaves > > + // it as it is. > > + ptr = match unsafe { A::realloc(Some(buf.cast()), layout, flags) } { > > Why would you shrink it? You can just keep the capacity. What if the vector was pretty huge and meanwhile as advanced by a lot? I think we don't want to waste those resources. Ideally the corresponding `Allocator` implements a proper heuristic for when to actually shrink. For instance, krealloc() never shrinks, and it's probably not worth it. For vrealloc() though we clearly want to shrink properly (i.e. unmap and free spare pages) at some point. > > Alice >