From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (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 24DDF29E115; Wed, 11 Feb 2026 14:07:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770818866; cv=none; b=rGFCXY73Bn+HmeemQQLGLydXbxWlAj3FXcZ8dJb5dO7Po+16nLRg/kVvxFhjtLVFZzg+WSKwaI6U0k89cbzG3l2BKzz2rjtRgs1dRHrUBeHGFrflZ3vGSX37960xR+II1rymCg9GR/WHlUH8yUYlGo73V0z36PFc6D5zHa6TuFM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770818866; c=relaxed/simple; bh=zymFyWB1i9bpCZtAij0v0RD6V026ENlBOWVqUgQQujM=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NKrqeivS+Jm9Vp45xuAJ78mtkDvAPkxgcZsUWUQwy4tZ/ikVVqu4nKZMZH03eeCa2cKElITEa7A+fhuO/M1OUMBEVOl/UPZIvVWDLKtFQAnopM1T2MVqS1W3owr06Dte960rpreyIswxp/5IGnF6rsok7k3f8yufTGlwt/kLgmY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=hMpVAZPD; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="hMpVAZPD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770818863; bh=zymFyWB1i9bpCZtAij0v0RD6V026ENlBOWVqUgQQujM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hMpVAZPDmoG5rR69sgP2ygrmhoB6fQZghIuwZFJm055FPGzglzG0Lz2fKN2pkTLXZ q0lY9XoBHLa68magnhu2PZHnKt4g5E4h5c2eE8Imi9L6v57wIHzYCsIl/NBU9Xloes nqtlUuJ5bcsu2gwf+eRHIgxSns4SQaPMlC2uH6yMhQfW3e0Ri0T9EeDliQZUPtXX/E B9AkZ4N6ZpIKx6iWLF6KpMW+kXb5uTQA0qJ5R2EeqydkPmUBnD+4YTzIG5ONAubDn+ wjz+9i0eilD/uE2gXa1FdD2oZjvmJCVU3CUwb3KDf4yekqxtqOREhLesV9A34D//uR ee5Y7nGJDrFZg== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id E798817E13A5; Wed, 11 Feb 2026 15:07:42 +0100 (CET) Date: Wed, 11 Feb 2026 15:07:38 +0100 From: Boris Brezillon To: "Gary Guo" Cc: "Alice Ryhl" , , "David Airlie" , "Simona Vetter" , "Danilo Krummrich" , "Benno Lossin" , Christian =?UTF-8?B?S8O2bmln?= , "Daniel Almeida" , "Joel Fernandes" , , , Subject: Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue Message-ID: <20260211150738.049af4bb@fedora> In-Reply-To: References: <20260203081403.68733-2-phasta@kernel.org> <20260203081403.68733-5-phasta@kernel.org> <20260210155750.5cdbe6cc@fedora> <8ea48ce49f2c7b6fd715dd54c24e755e8ac3262c.camel@mailbox.org> <20260211120742.0e9e7122@fedora> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 11 Feb 2026 21:45:37 +0800 "Gary Guo" wrote: > On Wed Feb 11, 2026 at 8:22 PM CST, Alice Ryhl wrote: > > On Wed, Feb 11, 2026 at 12:19:56PM +0100, Philipp Stanner wrote: =20 > >> On Wed, 2026-02-11 at 12:07 +0100, Boris Brezillon wrote: =20 > >> > On Wed, 11 Feb 2026 11:47:27 +0100 > >> > Philipp Stanner wrote: > >> > =20 > >> > > On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote: =20 > >> > > > On Tue,=C2=A0 3 Feb 2026 09:14:02 +0100 > >> > > > Philipp Stanner wrote: > >> > > > =C2=A0 =20 > >> > > > > +/// A jobqueue Job. > >> > > > > +/// > >> > > > > +/// You can stuff your data in it. The job will be borrowed b= ack to your driver > >> > > > > +/// once the time has come to run it. > >> > > > > +/// > >> > > > > +/// Jobs are consumed by [`Jobqueue::submit_job`] by value (o= wnership transfer). > >> > > > > +/// You can set multiple [`DmaFence`] as dependencies for a j= ob. It will only > >> > > > > +/// get run once all dependency fences have been signaled. > >> > > > > +/// > >> > > > > +/// Jobs cost credits. Jobs will only be run if there are is = enough capacity in > >> > > > > +/// the jobqueue for the job's credits. It is legal to specif= y jobs costing 0 > >> > > > > +/// credits, effectively disabling that mechanism. > >> > > > > +#[pin_data] > >> > > > > +pub struct Job { > >> > > > > +=C2=A0=C2=A0=C2=A0 cost: u32, > >> > > > > +=C2=A0=C2=A0=C2=A0 #[pin] > >> > > > > +=C2=A0=C2=A0=C2=A0 pub data: T, > >> > > > > +=C2=A0=C2=A0=C2=A0 done_fence: Option>>, > >> > > > > +=C2=A0=C2=A0=C2=A0 hardware_fence: Option>= >, > >> > > > > +=C2=A0=C2=A0=C2=A0 nr_of_deps: AtomicU32, > >> > > > > +=C2=A0=C2=A0=C2=A0 dependencies: List,=C2=A0 =20 > >> > > >=20 > >> > > > Given how tricky Lists are in rust, I'd recommend going for an X= Array, > >> > > > like we have on the C side. There's a bit of overhead when the j= ob only > >> > > > has a few deps, but I think simplicity beats memory-usage-optimi= zations > >> > > > in that case (especially since the overhead exists and is accept= ed in > >> > > > C).=C2=A0 =20 > >> > >=20 > >> > > I mean, the list is now already implemented and works. Considering= the > >> > > XArray would have made sense during the development difficulties. = =20 > >> >=20 > >> > I'm sure it does, but that's still more code/tricks to maintain than > >> > what you'd have with the XArray abstraction. =20 > >>=20 > >> The solution than will rather be to make the linked list implementation > >> better. > >>=20 > >> A list is the correct data structure in a huge number of use cases in > >> the kernel. We should not begin here to defer to other structures > >> because of convenience. =20 > > > > Rust vs C aside, linked lists are often used in the kernel despite not > > being the best choice. They are extremely cache unfriendly and > > inefficient; most of the time a vector or xarray is far faster if you > > can accept an ENOMEM failure path when adding elements. I have heard > > several times from C maintainers that overuse of list is making the > > kernel slow in a death from a thousand cuts situation. =20 >=20 > I would rather argue the other way, other than very hot paths where cache > friendliness absolutely matters, if you do not require indexing access th= en the > list is the correct data strucutre more often than not. >=20 > Vector have the issue where resizing requires moving, so it cannot be use= d with > pinned types. XArray doesn't require moving because it requires an indire= ction > and thus an extra allocation, but this means that if you're just iteratin= g over > all elements it also does not benefit from cache locality. Back to this particular job dependencies use case: we have to embed the DmaFence pointer in some wrapper with the ListLinks element anyway, because DmaFences can be inserted in multiple of those lists in parallel. This means that now the overhead is two-pointers per DmaFence pointer. Of course, it's not a big issue in practice, because those elements are short-lived, it's only 16 bytes, and if we're ending up having too many of those deps, we're gonna have other challenging scaling issues anyway. But it also means we have the extra-indirection that you'd have with an array of pointers or an xarray, with more per-item overhead, and none of the advantages a list could provide (O(1) removal if you have the list item, O(1) front insertion, ...) would really be used in this case (because we use the list as a FIFO, really). So overall, I'd still lean towards an XArray here, unless there are strong objections. Just to make it super clear, I'm not making a case against all List usage, just this particular one :-).