From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 018B82F363F for ; Fri, 10 Jul 2026 15:09:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.221.180 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783696173; cv=pass; b=AeaBqykfjWTYd2eACczW7P6wDNAUuo7Gligw4jQvljw8oi4m8tqLAa9e+D5qnnoNPqdb03h2HNv0cJ5M9dJtvwSTU3FL84epyz8JqbgVqyqLgZgyjJolpASz8vm/eJWh/Ypo3XqzCqLS4azwe8Iv3SrrApEPCGFtw3NHVGdbeI4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783696173; c=relaxed/simple; bh=wFZ3WcatDhR5uImQkZGjiMV/Fklf+6X2ZjKbOG/rOjM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pv8GWtMSeJuQx6De8ecljLq2c/1qh00JVj/kNZ9J32DigTNRAB8Jq2jW/qGAAC9b9N/ejtZZSqv8O2/Ah0tjQj0YM2FXXph8vyKlrMkIHgDR6Hjd88M05PanC7Gh2msXVJuttt0BFvK5rm2gdw3mRpJO/iPV58oM2gj5SU7j0TM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=N6a93qI1; arc=pass smtp.client-ip=209.85.221.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="N6a93qI1" Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-5bf94664327so573506e0c.1 for ; Fri, 10 Jul 2026 08:09:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783696171; cv=none; d=google.com; s=arc-20260327; b=gTQrAhSKvw+UP9Cr9kP4rt5tIbYERDuhypUPbS1rJL+nid6S9/9+MxUWZcX7PCaS2Z nQsmGx0+H3mcFq3sxLH3CcCl0PopBfxCOqfa/ICnbRaS3v0UGgpYA8l6w6kul29qtQI5 p012dT0c8zjGrIYnh4ZRmKc2LasKAHaFAq4Zt07fnxHb7DxeAUTBRZBNh+a8uUtQeiFf YXaxM00jVZUod0U8NSa2oB0KanhRScqfzMDo8O5MFcmIVN8kOM+6S5MC8+bO+95D+eIG 5LpaZgU5WoTUydUUfxzfJUk3rYa9X24XjcA3v/qORX434zjDMppOPkYugFfJJsvRpgDn rXhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=xXUgud4G/O9l9flAkvY3taGec20Vgh1cA8EQbaLr8+g=; fh=aObsxwDf6gsu/X7aOOQ6h23DKqzGfekbrWstltAbTkc=; b=Zbw9LDdCEPkvCh11Gy9jViyuvzbdU18ieJLHf4VixjDPpYnOR9tCyOPGK7bqcSfs2p GQxsqP8Of/cstQR4IPksM7V7hwVwjbCThyMYEGkP1wR8hHDR+wN9z4rqiqj8D1ZxKNBm 17yIWMECXt9t2oJQSURsI/tun4iXAOUevlOoWtvRN0AYX4xfln0Tkz0fDO/U+pMYEsby 4d01YjSlK9bb+gre1qU5M0My7GPmBIx8fPoLvhnkMcthVzqc6iNOzZPqnTSu5vH070qM wwM2dtKLSyF+Vs8eLRszWSI2zCu+vc5AH65LKmhU/QpU3k7ul0v4Xa6SB5vX/Fr2R2xA RJyQ==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783696171; x=1784300971; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=xXUgud4G/O9l9flAkvY3taGec20Vgh1cA8EQbaLr8+g=; b=N6a93qI1ROa+Lyk62cqjsMnPCJdF0ro4nIGjWR5tyshmeMrbE9dTRsCZIFeQhCRHNs zzVT/RLk3rxoBMV+dcDcG8Ffti0e8Sn8N6Ff0VS7moEfE9gtRVY3qOhYoxy0OMOfXUfb CbZp8kXzZ2QoptIf3k8CIpZvv/bGYKs7rrWT4IQ+cgsmlOxGDBhPMNDe4+tzAdfOXjuK H4Mh/vso7M3x0zmmqOUZKDyQ4grhNH1b5GjF0b3WYiyFXtsOfWieCSbIru74aMxuTGsM jp/oCDDX8nfNuuEZPnCkmCtveSSIHN/9flGnqw+nYeqpGL37oTPb/i/HiwjVJUcm6w3v +YQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783696171; x=1784300971; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=xXUgud4G/O9l9flAkvY3taGec20Vgh1cA8EQbaLr8+g=; b=dg1IlHKrFs9OGnB0HzoepzqkgTdXTiY9HH3pKh4hChWaqic/RYcJXBho0mKatH3eLS nCHh+411oQFgN+C1wnV8BSYz6piaP62Pksl3TGQyVT0KZ2SHNPTiqP5zIJDkvFONzSnp hxItfKpKJ2HimYU6d6VLu4h2mVYiJX85XmxN1gay60sqfTai5TiJ8byyjhGx37h7D3lX keacoQSyyvxIqvqY33uTaD5FX6foNwKRpAT2yBZBebieaXYwjaABMuzBe923G1wiHWe6 LDRcFYrvg45Dx/EkNjqr7SItkWhaLR9hTA16QGIPPVzieJJwkzeT7kUNx+JRZa2n1BYx O6Pg== X-Forwarded-Encrypted: i=1; AHgh+Rqax+cQrMtmIgqVM0ufJ710eH8bHb4TxRsxepY0gj7WnBta/QZSpQvh/tbmtWN0i6qQhZskaozaf5JjtRE=@vger.kernel.org X-Gm-Message-State: AOJu0YzCR0iUt88A2n268Pe3Od1ODD42FI2PE/SsmQjMot4HLK2gLzPq omklxROXwOGHTAUZ73ukmukzgVWmm2EQkuTvpGBXOiUVNcSPXu+HKsKefTg1wV5tB2Hfzj8yUc7 QwzWi7IU3LnExHhao1gOv7m3lb6QXuU4= X-Gm-Gg: AfdE7cmlYlBPgGme4qbw7ed3aLUfgJFOq0vxsywAmx51JcBa6ZeSKz53jv4NPVU0+Ju EG3k+8BNnyCB2rYT4nGqrn+ZgJ19qIQriJc+S6kwgN2C64p2AylAap3CktNQSb4cYxxjGMVy9a9 OT19CdWSx2Tc0Nnk5aElcxRhuJpbs1O/ccRxInW5h2xInt7iON70gSy3rRSt/CvFJ50SzQ9Ea16 6BnHwjgLggvJmhjGWRejvL8lAoBu9LgYG3xsHlG/fSj1cDyTe1kPu5ltz58RBToZpkZCfa3/MlS Z6lQ2kFhNDj1DuuMtZSFed07SoIgyZ5M9coKug== X-Received: by 2002:a05:6122:2883:b0:5bd:81fc:ebe9 with SMTP id 71dfb90a1353d-5bf75a9fa9cmr6210645e0c.0.1783696170828; Fri, 10 Jul 2026 08:09:30 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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> <2026070839-quadrant-gentleman-2334@gregkh> In-Reply-To: From: Burak Emir Date: Fri, 10 Jul 2026 17:09:16 +0200 X-Gm-Features: AUfX_mz71O6wKNiBjknUzlHPuRHRfhmrp1Ke1wablmRwTKjPL09QiGzeg2wSZG8 Message-ID: Subject: Re: [PATCH 3/4] rust: id_pool: add contiguous area allocation To: Alice Ryhl Cc: Yury Norov , Greg KH , Eliot Courtney , Yury Norov , Miguel Ojeda , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Daniel Almeida , Tamir Duberstein , Alexandre Courbot , =?UTF-8?Q?Onur_=C3=96zkan?= , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 8, 2026 at 11:08=E2=80=AFPM Alice Ryhl w= rote: > > On Wed, Jul 08, 2026 at 04:37:38PM -0400, Yury Norov wrote: > > On Wed, Jul 08, 2026 at 07:33:16AM +0200, Greg KH wrote: > > > > ... > > > > > > I asked exactly the same question when Alice and Burak added wrappe= rs > > > > 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 i= s > > > > preferable for a basic data structure like bitmaps. It enables Ru= st > > > > code to be a lot more similar and predictable with respect to C c= ode > > > > that uses the same data structures and enables the use of code th= at > > > > has been tried-and-tested in the kernel, with the same performanc= e > > > > characteristics whenever possible. > > > > > > > > And now it's in a commit message: 11eca92a2caeb > > > > > > > > They measured the affect of their wrapper on performance, and it ap= pears > > > > to be ~5%. See lib/find_bit_benchmark_rust.rs. > > > > > > You are comparing the C vs. Rust data structures here, which is not w= hat > > > I am proposing. > > > > > > Also, is this code being used on a "hot path" like the binder stuff i= s? > > > > > > > I didn't see any side-to-side comparison between any native Rust AP= I 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 ask= ing > > > to use the C structures like maple-tree and idr instead of open-codin= g > > > logic around the bitmap code. > > > > I understand your point. I asked both questions: are they sure that bit= map > > is the most optimal data structure for the ID pool, and if so, why not = use > > the built-in Rust bitmaps? The answer was: yes, it's the most optimal, = and > > using built-in bitmaps is suboptimal overall. > > The Rust standard library doesn't really have a bitmap abstraction to > begin with, so if we want to use bitmap then it's either handrolled > bit-manipulation or the C bitmap api. > > cc'ing Burak's new email > (Thanks, I will update my email in the MAINTAINERS file.) Binder needs to acquire bits *while holding a spinlock*. This is the biggest constraint. My understanding is that the IDA API call might need to allocate memory (and sleep) when getting a new ID, as a side-effect. So for the binder use case, it was not an option. @Yury, about the alternative of vendoring Rust bitmap crates: that would have duplicated the kernel's C bitmap functionality. There does not seem much point in duplicating that, and opening the door to have Rust and C code differently named API functions and such. So beside performance, maintenance and coherence are also a factor. The Rust ID pool code is merely a port of some existing bitmap-specific binder C code (that can hopefully be deleted one day) that deals with spinlock allocation fun. If the constraints match, I think it is good to see it generalized and used elsewhere. That is a conditional statement, I am not familiar with the nova use case's performance/allocation/sleep constraints. -- Burak