On Tue, Oct 29, 2024 at 04:38:34PM -0400, Johannes Weiner wrote: > On Mon, Oct 28, 2024 at 11:05:48AM +0100, Maxime Ripard wrote: > > On Thu, Oct 24, 2024 at 07:06:36AM -1000, Tejun Heo wrote: > > > Hello, > > > > > > On Thu, Oct 24, 2024 at 09:20:43AM +0200, Maxime Ripard wrote: > > > ... > > > > > Yeah, let's not use "dev" name for this. As Waiman pointed out, it conflicts > > > > > with the devices controller from cgroup1. While cgroup1 is mostly > > > > > deprecated, the same features are provided through BPF in systemd using the > > > > > same terminologies, so this is going to be really confusing. > > > > > > > > Yeah, I agree. We switched to dev because we want to support more than > > > > just DRM, but all DMA-able memory. We have patches to support for v4l2 > > > > and dma-buf heaps, so using the name DRM didn't feel great either. > > > > > > > > Do you have a better name in mind? "device memory"? "dma memory"? > > > > > > Maybe just dma (I think the term isn't used heavily anymore, so the word is > > > kinda open)? But, hopefully, others have better ideas. > > > > > > > > What happened with Tvrtko's weighted implementation? I've seen many proposed > > > > > patchsets in this area but as far as I could see none could establish > > > > > consensus among GPU crowd and that's one of the reasons why nothing ever > > > > > landed. Is the aim of this patchset establishing such consensus? > > > > > > > > Yeah, we have a consensus by now I think. Valve, Intel, Google, and Red > > > > Hat have been involved in that series and we all agree on the implementation. > > > > > > That's great to hear. > > > > > > > Tvrtko aims at a different feature set though: this one is about memory > > > > allocation limits, Tvrtko's about scheduling. > > > > > > > > Scheduling doesn't make much sense for things outside of DRM (and even > > > > for a fraction of all DRM devices), and it's pretty much orthogonal. So > > > > i guess you can expect another series from Tvrtko, but I don't think > > > > they should be considered equivalent or dependent on each other. > > > > > > Yeah, I get that this is about memory and that is about processing capacity, > > > so the plan is going for separate controllers for each? Or would it be > > > better to present both under the same controller interface? Even if they're > > > going to be separate controllers, we at least want to be aligned on how > > > devices and their configurations are presented in the two controllers. > > > > It's still up in the air, I think. > > > > My personal opinion is that there's only DRM (and accel) devices that > > really care about scheduling constraints anyway, so it wouldn't (have > > to) be as generic as this one. > > If they represent different resources that aren't always controlled in > conjunction, it makes sense to me to have separate controllers as well. > > Especially if a merged version would have separate control files for > each resource anyway (dev.region.*, dev.weight etc.) > > > And if we would call it dma, then the naming becomes a bit weird since > > DMA doesn't have much to do with scheduling. > > > > But I guess it's just another instance of the "naming is hard" problem :) > > Yes it would be good to have something catchy, easy on the eyes, and > vaguely familiar. devcomp(ute), devproc, devcpu, devcycles all kind of > suck. drm and gpu seem too specific for a set that includes npus and > potentially other accelerators in the future. > > I don't think we want to go full devspace & devtime, either, though. > > How about dmem for this one, and dpu for the other one. For device > memory and device processing unit, respectively. dmem sounds great to me, does everyone agree? Maxime
Attachment:
signature.asc
Description: PGP signature
