On Fri, 1 Sep 2023 13:37:46 +0200 Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > On Fr, 01.09.23 13:13, Christian Pernegger (pernegger@xxxxxxxxx) wrote: > > > I don't know about this. Yes, seat1 could hog the GPU that seat0's > > outputs are attached to, or vice versa, but seat1 could just as well > > hog all the RAM or saturate the CPU. My point being, seats share the > > host's CPU power, RAM, ..., already, why not the rendering/compute > > power as well. IMVHO it's really just inputs and outputs that should > > be seat-specific. Restricting the shared resources available to a > > given seat, allocating them fairly, etc., is a different problem (and > > arguably one that I'd tackle per user and not per seat). > > CPU/RAM are by default resource managed, i.e. each user logged in gets > a similar amount under pressure, as controlled via the cgroups > logic. > > This is different from GPU resources, there's no such reosurce > management for that. If you mean cgroup resource limits for GPUs, yeah, it's not there yet, but I've seen people trying to add them. It just seems difficult to define what those resources are exactly and how to measure them in a sensible way, since GPUs have wildly different execution unit architectures. I'm not sure what the current patch state is. Thanks, pq
Attachment:
pgpQrDw5BzThm.pgp
Description: OpenPGP digital signature
