On Mon, Feb 20, 2023 at 8:44 AM Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > > > On 20/02/2023 15:52, Rob Clark wrote: > > On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin > > <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > >> > >> > >> On 17/02/2023 20:45, Rodrigo Vivi wrote: > > [snip] > > >> Yeah I agree. And as not all media use cases are the same, as are not > >> all compute contexts someone somewhere will need to run a series of > >> workloads for power and performance numbers. Ideally that someone would > >> be the entity for which it makes sense to look at all use cases, from > >> server room to client, 3d, media and compute for both. If we could get > >> the capability to run this in some automated fashion, akin to CI, we > >> would even have a chance to keep making good decisions in the future. > >> > >> Or we do some one off testing for this instance, but we still need a > >> range of workloads and parts to do it properly.. > >> > >>>> I also think the "arms race" scenario isn't really as much of a > >>>> problem as you think. There aren't _that_ many things using the GPU > >>>> at the same time (compared to # of things using CPU). And a lot of > >>>> mobile games throttle framerate to avoid draining your battery too > >>>> quickly (after all, if your battery is dead you can't keep buying loot > >>>> boxes or whatever). > >>> > >>> Very good point. > >> > >> On this one I still disagree from the point of view that it does not > >> make it good uapi if we allow everyone to select themselves for priority > >> handling (one flavour or the other). > > > > There is plenty of precedent for userspace giving hints to the kernel > > about scheduling and freq mgmt. Like schedutil uclamp stuff. > > Although I think that is all based on cgroups. > > I knew about SCHED_DEADLINE and that it requires CAP_SYS_NICE, but I did > not know about uclamp. Quick experiment with uclampset suggests it > indeed does not require elevated privilege. If that is indeed so, it is > good enough for me as a precedent. > > It appears to work using sched_setscheduler so maybe could define > something similar in i915/xe, per context or per client, not sure. > > Maybe it would start as a primitive implementation but the uapi would > not preclude making it smart(er) afterwards. Or passing along to GuC to > do it's thing with it. > > > In the fence/syncobj case, I think we need per-wait hints.. because > > for a single process the driver will be doing both housekeeping waits > > and potentially urgent waits. There may also be some room for some > > cgroup or similar knobs to control things like what max priority an > > app can ask for, and whether or how aggressively the kernel responds > > to the "deadline" hints. So as far as "arms race", I don't think I'd > > Per wait hints are okay I guess even with "I am important" in their name > if sched_setscheduler allows raising uclamp.min just like that. In which > case cgroup limits to mimick cpu uclamp also make sense. > > > change anything about my "fence deadline" proposal.. but that it might > > just be one piece of the overall puzzle. > > That SCHED_DEADLINE requires CAP_SYS_NICE does not worry you? This gets to why the name "fence deadline" is perhaps not the best.. it really isn't meant to be analogous to SCHED_DEADLINE, but rather just a hint to the driver about what userspace is doing. Maybe we just document it more strongly as a hint? BR, -R > Regards, > > Tvrtko
