From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (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 8A9AF3C276E for ; Sat, 11 Jul 2026 12:28:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783772925; cv=none; b=fh52lPKMMzuwhgGbyQZK4Kj9pg96TXFF0mqTELqLj5kkmI949DTGu/JSfALMEvSWbQ0f9fICccBh4ebKaxjZEV+r/4FD3lgMV/uAgcqhawMuVd4CFj1h5KxRiqONKCbgtsPcHDTL5AA7WraMRYJCgSRXFzy9zZRGpOFj96rvmMk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783772925; c=relaxed/simple; bh=QM0bVPxlx46ODCacqIIoJuIOnDtNgXJ0Hb7nJeo8Aqs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=oQaMlVUZwCD+R65AsDZZ6aXO0uDVNetJMGhXwvGT6JQ/YxRa71V5+Db8ony1zvUk/5EXHJqUgrCYfINXARRroniDFN8tYGGULalZh9r56jG1mmizjL+x3wmI3VX2rjnRIhIaTf5JNeAqEyMkhBmvhZO8T06LPdxeEPuW9rZYz7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=QmpVmCg+; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QmpVmCg+" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-493ae2a6a72so17597465e9.0 for ; Sat, 11 Jul 2026 05:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783772922; x=1784377722; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1zqV6pU7J/up3BiO4WkzdnwyvKk4FnHi04KFj10WU3o=; b=QmpVmCg+2DNDDL2jg/dOAqzehKJq6fzrkVvm8P8cYCuP3BR8NwYx+S1OKfahrxBR87 YOZ07u6JohqtQ4Q3Mtc5gb6/n/QWV/MhmKWiQiGxGkblwRjgcHGA/xy0xcUU76K4ms+/ 7pASUuEE00DEze9jHf8x8bXEMcCqhfhnfF1RnWewv9fde6Z7QmkGtELK2tFtbxqd57eK +o93/uAF9O08iBBOWAt2duNnfMasXHkx780Pej/oG6O2VwMTz4eME5/qkW+Evy4LsktE EzQ2wpChe7LBCPL2Gq6Ghra/ZJ4rOFKO+i4kowlSBVYBXvHSn/ptSlLubzWGeh1BPmWV KKoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783772922; x=1784377722; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1zqV6pU7J/up3BiO4WkzdnwyvKk4FnHi04KFj10WU3o=; b=a0e6Rt+SvfVsu3fakeuffZnPJzHBBhYcOb0rblfDPif5xWekuHN6PqNKBu6ZZ9fc+D wrXSAico9cA39joVMNpPUxuxe8jr2UWsWx2NJu1Etpc50hp2N26ONdjxn1gHtfczwVBo eo8WyPtGdExSJuL3ZNKZSX1kveZ5AY4nuoL/g+Rg/eypbZEnt+uQ1YoQzf6xGht+90Qm oiOOQTUZ9CPNTZmfQ2F+6ySw8TsfssOHIpkVSk3JUJqUNwk4+fA5cVhkU5YpLJxHTvg7 5OAG5JO0GN6kDnIYgutzfiKYPGKpuaa3IDxnV42KbZ9fKWEAM5a80N4+bJiyVe/tvZ0E JfMQ== X-Forwarded-Encrypted: i=1; AHgh+RqM0OOP4YplgLZfTdaQV0jKak186Q9+OmC3dczMCILwNp9FCK2OQx5uhv03XlgGER7HkxBtU8CbIFlDRZs=@vger.kernel.org X-Gm-Message-State: AOJu0YyCk8ID/XqM26Lo85F7oF2wZy5WAFEknWaRDvfFfD4MCmKWW6J7 OJ41q/4Oo9Js8O4NnCXKvIpbdAH7DqVLYxSFhXVtOxlOblwoUZ0jY7+Lm9ybtbZJsUrRKG0CA/5 Bs97WrOpBvzqjPy/oHw== X-Received: from wrue11.prod.google.com ([2002:a5d:4e8b:0:b0:46c:d068:1ef8]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:6692:b0:493:bf84:53d8 with SMTP id 5b1f17b1804b1-493f87e472cmr24827145e9.9.1783772921797; Sat, 11 Jul 2026 05:28:41 -0700 (PDT) Date: Sat, 11 Jul 2026 12:28:40 +0000 In-Reply-To: <84bc8bd2-e292-4b84-9580-a1b5df4c5bdc@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260710-chid-maple-v1-1-4ee869055268@nvidia.com> <84bc8bd2-e292-4b84-9580-a1b5df4c5bdc@nvidia.com> Message-ID: Subject: Re: [PATCH] gpu: nova-core: add ChannelIdPool From: Alice Ryhl To: John Hubbard Cc: Eliot Courtney , Danilo Krummrich , Alexandre Courbot , David Airlie , Simona Vetter , Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Daniel Almeida , Tamir Duberstein , "Onur =?utf-8?B?w5Z6a2Fu?=" , Greg KH , Burak Emir , Yury Norov , Alistair Popple , Timur Tabi , Zhi Wang , linux-kernel@vger.kernel.org, nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" On Fri, Jul 10, 2026 at 02:29:39PM -0700, John Hubbard wrote: > On 7/10/26 6:42 AM, Eliot Courtney wrote: > ... > > +use kernel::{ > > + maple_tree::MapleTreeAlloc, > > Hi Eliot, Alice, all, > > Eliot already laid out the maple costs (the alloc_range+erase loop > replicating find_next_zero_area, the extra mutex, allocation on > alloc and free), so I won't rehash them. What I can add is why the > alignment is a hard requirement, since that is what seems to make > the decision clearer to me at least. > > Pre-Blackwell, USERD sits in BAR1 at page granularity, 8 channels to a > 4K page (chid = page*8 + slot). Giving a VM its own channels means > giving it whole USERD pages, so a VM's chid range has to be 8-aligned > and a multiple of 8. Blackwell moves submit to a per-function doorbell > keyed by (runlist, chid), and the constraint goes away. So it's a > constraint we're stuck with pre-Blackwell, not one we can design away. > > Given that, the bitmap version is hard to argue with. The aligned > allocation is the one call the API is built around, roughly: > > let mut ids = self.inner.lock(); > let area = ids.find_unused_area(0, count, align_mask) > .ok_or(ENOSPC)?; > // area.acquire() reserves and returns the range, drop clears it > > One lock, no retry, and release is a bitmap_clear that can't fail. For > 2048 IDs the backing store is a 256-byte array. find_next_zero_area() > is also the existing idiom for this (IOMMU, DMA, IRQ), so it answers > Greg's reuse-what-exists point as well. > > I'd go with the bitmap id_pool. Completely agreed. The loop in this patch seems like a really bad idea to me. If the maple tree doesn't natively provide a way to allocate the range with an alignment requirement, we should not attempt to hack in support for alignment by looping. Please use the bitmap. (Even without the alignment requirement, I think that the 2048 size limit is also a good reason to use a bitmap, but the argument is less strong in that case.) Alice