From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF47B363C75; Wed, 8 Jul 2026 05:33:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783488801; cv=none; b=VLo9QmUgITjbQ6H/ulcsccI0ZMWlJIykB4bZvM7YTwFjBiRWy+IVMx/QNFXtyjtOSUYs1/+Fn0HKb4CpWa9hcSG082JZtqaC1tazTXdPKNUb2GjdT17BArodNcTOIhnx1q5Q3tugh834yUxCFrlJkkXkbIoT21Y1NhYiSJlf7P4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783488801; c=relaxed/simple; bh=3t4X0QDl+bT+gyOUIts/28lvEOWzKR0WAuSUJXofI+U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TFMIL1yBqcFSCbY8x14vscm9qftVH/QiDd1l4ro8Upq1qsEgS6cjHvT4vJNuzCC4Og7mdsTWqIG6w/GwCJS5T8VkSHGeJG6QUZsD4mbpPj+0FXX6rKAAEMBKJDGpE08g6valDlh4W/m/NTDIXDfflNywe+epdhBGyYqr3TsZKyM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ickX3Tog; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ickX3Tog" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 093331F00A3E; Wed, 8 Jul 2026 05:33:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1783488799; bh=mMaPgHn6LKK741pznqikoYQd8ZVAb02xm7w612bJCcw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ickX3TogilGPdFLnxstj6n81B//8drCBx+ZPJgKRzk+nEcAiTcVVFHaRRJClHuBLn cnkT1TYylN5X9JmWxc64DGrpvzc1gHEd+PyNn11u7k9L2fcd9S8guDy2GdbAZAS4yW cFGl4g0cs7uLsWUAx3RjN+e9ctAc8WYwuUutz1vs= Date: Wed, 8 Jul 2026 07:33:16 +0200 From: Greg KH To: Yury Norov Cc: Eliot Courtney , Alice Ryhl , Burak Emir , Yury Norov , Miguel Ojeda , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Daniel Almeida , Tamir Duberstein , Alexandre Courbot , Onur =?iso-8859-1?Q?=D6zkan?= , David Airlie , Simona Vetter , John Hubbard , Alistair Popple , Timur Tabi , Zhi Wang , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org, dri-devel Subject: Re: [PATCH 3/4] rust: id_pool: add contiguous area allocation Message-ID: <2026070839-quadrant-gentleman-2334@gregkh> References: <20260703-chid-v1-0-84fe8259e46e@nvidia.com> <20260703-chid-v1-3-84fe8259e46e@nvidia.com> <2026070334-dollar-hexagram-e49c@gregkh> <2026070745-unwired-maybe-769e@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jul 07, 2026 at 12:31:08PM -0400, Yury Norov wrote: > On Tue, Jul 07, 2026 at 04:13:30PM +0200, Greg KH wrote: > > On Tue, Jul 07, 2026 at 10:25:27PM +0900, Eliot Courtney wrote: > > > On Fri Jul 3, 2026 at 7:31 PM JST, Greg KH wrote: > > > > On Fri, Jul 03, 2026 at 07:16:06PM +0900, Eliot Courtney wrote: > > > >> Add support for contiguous area allocation. Add a new type, > > > >> `UnusedArea`, following the same pattern as `UnusedId`. > > > >> > > > >> Signed-off-by: Eliot Courtney > > > > > > > > Why isn't the built-in idr library being used here instead of rolling > > > > your own data structure? > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > For nova-core in this series, we need allocation of a contiguous > > > sequence of IDs with a specific length and sometimes a specific > > > alignment. IIUC, IDA/xarray do not support that (I checked > > > ida_alloc_range and it only allocates a single ID in a range, not a > > > contiguous sequence). > > > > > > For IdPool before this series, I think it could have used IDA/xarray. > > > See [1] where Alice has posted some more context. > > > > > > w.r.t. the structure choice, the IDs we need to allocate are channel > > > IDs, and the total range is limited to 2048 of them, so IMO bitmaps are > > > a better fit than e.g. maple tree. > > > > But again, you are having to "roll your own" logic here, please reuse > > the data structures we already have in the kernel for this type of > > thing. If a maple tree works, please use it. > > I asked exactly the same question when Alice and Burak added wrappers > for bitmaps to implement their ID pool. This is the answer: > > An alternative route of vendoring an existing Rust bitmap package was > considered but suboptimal overall. Reusing the C implementation is > preferable for a basic data structure like bitmaps. It enables Rust > code to be a lot more similar and predictable with respect to C code > that uses the same data structures and enables the use of code that > has been tried-and-tested in the kernel, with the same performance > characteristics whenever possible. > > And now it's in a commit message: 11eca92a2caeb > > They measured the affect of their wrapper on performance, and it appears > to be ~5%. See lib/find_bit_benchmark_rust.rs. You are comparing the C vs. Rust data structures here, which is not what I am proposing. Also, is this code being used on a "hot path" like the binder stuff is? > I didn't see any side-to-side comparison between any native Rust API vs > imported C bitmaps. I'm sure, I asked for that, and I still believe > it's the important piece of data to avoid this back-and-forth type of > discussions. So, Alice, Burak or anybody... Again, I'm not talking about Rust API vs. imported C bitmaps, I'm asking to use the C structures like maple-tree and idr instead of open-coding logic around the bitmap code. > > > > Why isn't the built-in idr library being used here instead of rolling > > > > your own data structure? > > Now having more context, the ID pool's primary goal is to allocate > individual IDs, which naturally lays on find_bit() API in C. The > native Rust alternative is considered and found 'suboptimal overall'. Allocating IDs is a probe() thing, which can be as slow as it wants, right? Or is this some other hot-path where performance matters? The patch was not very specific as to the tradeoffs needed. thanks, greg k-h