On Sat, Jan 20, 2018 at 10:40:19AM +0000, Chris Wilson wrote: > Quoting Chris Wilson (2018-01-20 09:36:10) > > Quoting Matt Roper (2018-01-20 01:51:40) > > > GPU contexts are usually created with "normal" priority as a starting point and > > > then may be adjusted from their either via explicit methods (context_set_param) > > > or implicit methods (boosts/penalization due to runtime behavior). Let's allow > > > a system integrator to override this starting GPU priority for a group of > > > processes by setting a parameter on the cgroup that these processes belong to. > > > > You are still allowing a process to undo the cgroup by changing its > > own priority. What you want I think is a priority-offset or somesuch. > > Along this vein, it's worthwhile pointing out that the current scheduler > is not even close to being the cgroup-enabled CFS implementation it > needs to be to call itself a scheduler. (It's more or less a no-op > scheduler.) It may be premature to start exposing hooks into it. > -Chris I think that probably depends a bit on what you need from a "scheduler." The current i915 scheduler isn't fair (i.e., it allows higher priority processes to potentially starve out lower priority processes), but that winds up being exactly what we want in a lot of embedded use cases where the higher priority apps truly need absolute precedence over lower priority. Granted, in those kind of settings the higher priority apps tend to be curated, so there's already a reasonable expectation that they're well-behaved and won't overcommit the system. The suggestion of switching the cgroup to give a priority offset vs a priority starting point is a good suggestion though; thanks! Matt > -- > To unsubscribe from this list: send the line "unsubscribe cgroups" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
