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 0A612C52D6D for ; Fri, 2 Aug 2024 12:08:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 738096B007B; Fri, 2 Aug 2024 08:08:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E8046B0083; Fri, 2 Aug 2024 08:08:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AF346B0089; Fri, 2 Aug 2024 08:08:52 -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 3FA276B007B for ; Fri, 2 Aug 2024 08:08:52 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 906351C2280 for ; Fri, 2 Aug 2024 12:08:51 +0000 (UTC) X-FDA: 82407184062.29.A14AF06 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf30.hostedemail.com (Postfix) with ESMTP id BBBDF80002 for ; Fri, 2 Aug 2024 12:08:49 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fen8OUDo; spf=pass (imf30.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722600484; 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=eHyWZQCwAzQknHNs/4u2WfWGKffvhQCus1d6fv0WvYY=; b=BWL125JNKfZpqQBTrY3pvKCesEedyPPWEk5XP+tA+TdgN7v1hQ5MHvvuKdGLGMbmRzUWW0 65EleeKfWG748Qp3wgBclw9dIy6CkVfzThPYgw9LRc3fGckdhZlpzCy+ppFPIgYsDzLbW9 hMudcZbv2Wbiqb4CEX4kTRTGE4SM4gs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fen8OUDo; spf=pass (imf30.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722600484; a=rsa-sha256; cv=none; b=zr4W9PiIm2LAX2q67sXg08NcyTfkKMj0N3xBAoBWb1byWYNHkXm+8xX29kSfll8Cpvklp6 +v/O3/RyRrUZNiQ2JwLH+SBnJXJixssxLy0UQ+7m/GFJ/xqKCNCLk9HHjuAKGaJeOF97Rk 2EEKqphILYf/Cls7lLrXihL5l29orYU= Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-369cb9f086aso4431273f8f.0 for ; Fri, 02 Aug 2024 05:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722600528; x=1723205328; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=eHyWZQCwAzQknHNs/4u2WfWGKffvhQCus1d6fv0WvYY=; b=fen8OUDouIcihtBshRgesN1zft8GwE51vk+rVUVhH976lkF0/k6RAQSoGRLeSmpzQy CvMjZOOIo5QhMHLdXYCEZOmk1l6To8jjdYAtJVc2YcfsAkDd9fn1lfKUbPRMdMo8RxZy V5Jc7h5oAg2axsBv2yep6YUDVxUOey5uaz8mOGBlO49t7KfEEzHWx6kDtAqWB3xdszzi JWIKQK0F4rJHHBNPULK4EXs2R/tFel0O5eHeNVRFj5nwUbqOmnZdg5jj9uIxyKWIxs9f nhMbKPsqnvubsOEjqgougCyV7I/CKtdLHg2hiZfB3RyZlI3z3BSstoDLDpaZ8qqZ1LtF beHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722600528; x=1723205328; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eHyWZQCwAzQknHNs/4u2WfWGKffvhQCus1d6fv0WvYY=; b=Eml2R3pKXI8RtVXzDn0uyQoipPigWer80GzEUnGpYDCSHtY7K16CLrH2MeQqZ5iuXl FqkXD7hbGgmvPhZC7vbcEmAfUzMJuGnDtGDckmGoHBc9xYc9W67xlUqxUwKnUznq/8CB rK/3qn01AWdOZaKq6KyT5ksSlfb3FY9dNVSlOpLWYv99ckDSLX8xCzqkf1M/MJKCjda0 lnxG4dxltKHqDt+qRbwTpoB49piSzzQi6Gp70od+uF2azUumcOgprMsvG3LTKWcCbsO8 esIFV3mhN6wOx31zIhOTAbPAbaUZMTaXf8mTPlFPLrLoHlLvlu8VHdddC/WKxmkgEj5K aXBg== X-Forwarded-Encrypted: i=1; AJvYcCVNiPO3PKRTX3Y7WdWZQYegee4IupuHPG9740aLmZyMjXtLhqje+OMdTD8TOyyN5+q2t+KoZGphRpG7JWR//ZqGWx4= X-Gm-Message-State: AOJu0YyRFDBfUHJ2KLALoQVePUCW/4JVoE2543rwEyINBmiOugdZ9iS7 AWnUxnwsNsZgfiq6vvwbZCEPHm4DBdoKtdS4yWtsLXdwNlJf1rLQ/jkR/HMCmvZ0oPGuTVk3tLx u0Jwtqv6HTkqdeKlxCrWK6PD6Qj7dTTR7UWDz X-Google-Smtp-Source: AGHT+IHUQIoAKU0b17lBQJOOrWix0tX/MFcyLMaAq9Rx+fL6Bj9Um408fLlcoHVSjOpbBU3D1Ra+KK0Y8i6i96gatpw= X-Received: by 2002:a5d:634d:0:b0:368:5a86:c1b7 with SMTP id ffacd0b85a97d-36bbc1c22cbmr1971836f8f.55.1722600527742; Fri, 02 Aug 2024 05:08:47 -0700 (PDT) MIME-Version: 1.0 References: <20240801000641.1882-1-dakr@kernel.org> <20240801000641.1882-18-dakr@kernel.org> In-Reply-To: From: Alice Ryhl Date: Fri, 2 Aug 2024 14:08:34 +0200 Message-ID: Subject: Re: [PATCH v3 17/25] rust: alloc: implement `collect` for `IntoIter` To: Danilo Krummrich 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: dnpayfyh48q8fzhcneq7fsy1u51zmn9j X-Rspam-User: X-Rspamd-Queue-Id: BBBDF80002 X-Rspamd-Server: rspam02 X-HE-Tag: 1722600529-665175 X-HE-Meta: U2FsdGVkX19WbdKQ96lILkamjNrwU2PfP+ub6gG3zXRy16n69afZDib6lbON0x7nC2Oa3+EnDMX/nh/bCi4UUxL1ujt5hwZFrsmB6w4DyoyGerGtT8aN1uMmOeBKDDhs2MN+m1COWHD3wM3Z6reO5VSrZc4MF79wwYiPBXF8ktZe80pSGgrF9hrVcLAXIJPpw5QXmNPAPl39rX1ia1pixz9uK1wuzazJwr+Ww2sihYBKNJI0u+kid1b7eIduX9QOO3NBn0XlM1/t6bgRG/BXvN5eP4SlD3nX361E5NAxWKXnEXGU1beWSMC4wNBxnyeWZu6l3PEDBli0vNfQrjP09IwSWwKLo7f+MawpENBheHNCZ6flvoXW5lgfweTKDd9CufseYTRib7hLfKAEKjr8IzdqAwiTEJIZRrjmcWiAv26Rz7EMLFwW1Vu4RhIMxtkDX5CQ3ortQGs9X0kpU4rtkZHzIpYLWzWe/yScM+AL2UBw9xI/TlHZby6ymkUZ60tmsW7rFQcWtUOKtZuin+uHJtKnNHf0temBMHrz9BjxjkhdZxTtdBIIXRJGutTBpTtNFbjsyjiZLMPVNI7WevJGmKjSc3nd2AmQVM38FhSE8CKoDhqMYUp1cuUvtJKsoAox29mR4sGlMyzBIy/JrSFjGmaRN/aShLd5V0j0/r0VufmnehiAPdTHxT4UZzpOtLDvI82BINgx5j8mvHEUAv2HRRZ5M6+hnpInurp+LNCZZoUVUFFiiVdldrKX72xuHUGaUXSMZ1bEhMvwKWURkxs3A+10KcCACxHa1ZLJQmaEJKRGnyuJ8X3K4DwVwArZiwzPGbwB9afrBDrZODlfv6v98YMVVKUslbUJcAN9MZvF52YZ/gkJiTQlpi8J8DsmkM/SdjeTmAfrAtJNf2yIUz/SFsW8WDSNAHBeI+0euhPwkSwcoL5wX7B7NjAKZir9v8epuWd4uKLVa+Kwzu3M++A ov54puF+ vDaLTKJVM9s/JS15UierSX0vuci/k/eDh6DD0RpRu2A069ZKmuG5lNPUgGcVWz6gKv+hM3tH7MusNuqJYtSwbWP9q+0JTU7SWrGo7zlUIV1tJ9l2Tw5fgh04jkEKJgRIEHWM4HHVsruWU0xvzUD1LPal6OBid8S7Ktq/CZK5EA0b5IGT7KjlO5sSHxZqVvs7gtmbecV6FyMzG+HDm1x8Bc1+TV/Kylj6hrygNJqB2seGOWdYjfyH47KyVC2tdNlQ/pMePWmx8sInDQlqF6l/V7y1g/3efRMNqdZYEHoUbiRF/CdNz7qN3pzfFqdF4DakJi1vQTuJXAzWrKCStV2Lty57qI+O9xPIzGYDT X-Bogosity: Ham, tests=bogofilter, spamicity=0.019401, 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 Fri, Aug 2, 2024 at 2:02=E2=80=AFPM Danilo Krummrich w= rote: > > On Fri, Aug 02, 2024 at 09:08:48AM +0200, Alice Ryhl wrote: > > On Thu, Aug 1, 2024 at 5:37=E2=80=AFPM Danilo Krummrich wrote: > > > > > > On Thu, Aug 01, 2024 at 05:10:22PM +0200, Alice Ryhl wrote: > > > > On Thu, Aug 1, 2024 at 2:08=E2=80=AFAM 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 t= o > > > > > 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 arou= nd 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 al= location > > > > > failures. > > > > > - Neither `Iterator::collect` nor `FromIterator::from_iter` can= handle > > > > > additional allocation flags. > > > > > > > > > > Instead, provide `IntoIter::collect`, such that we can at least c= onvert > > > > > `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 poi= nt 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. > > > > If you have a need for a collect on this particular kind of iterator, t= hen okay. > > Even once we have our own `FromIterator` trait, we probably want to keep = this > specific one besides the generic `collect` for optimization. With the gen= eric > one we'd otherwise copy into a new `Vec`. > > > > > > > > + > > > > > + // SAFETY: `buf` points to the start of the backing buff= er and `len` is guaranteed to be > > > > > + // smaller than `cap`. Depending on `alloc` this operati= on may shrink the buffer or leaves > > > > > + // it as it is. > > > > > + ptr =3D match unsafe { A::realloc(Some(buf.cast()), layo= ut, 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 f= or when to > > > actually shrink. For instance, krealloc() never shrinks, and it's pro= bably not > > > worth it. For vrealloc() though we clearly want to shrink properly (i= .e. unmap > > > and free spare pages) at some point. > > > > The Rust Vec never shrinks unless explicitly requested. But I guess > > it's okay either way. > > It actually does, see [1]. But Rust's `Vec` does it less efficiently. It = either > keeps the `Vec` as it is, or creates a whole new one. > > [1] https://github.com/rust-lang/rust/blob/master/library/alloc/src/vec/s= pec_from_iter.rs#L39 Huh, surprising. Reviewed-by: Alice Ryhl Alice