[igt-dev] [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-09 17:06:45)
> 
> On 09/03/2018 13:46, Chris Wilson wrote:
> > Exercise some new API that allows applications to request that
> > individual contexts are executed within a desired frequency range.
> > 
> > v2: Split single/continuous set_freq subtests
> > v3: Do an up/down ramp for individual freq request, check nothing
> > changes after each invalid request
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Paneri, Praveen <praveen.paneri at intel.com>
> > Cc: Kamble, Sagar A <sagar.a.kamble at intel.com>
> > Cc: Antonio Argenziano <antonio.argenziano at intel.com>
> > ---
> >   tests/Makefile.am      |   1 +
> >   tests/Makefile.sources |   1 +
> >   tests/gem_ctx_freq.c   | 648 +++++++++++++++++++++++++++++++++++++++++++++++++
> >   tests/meson.build      |   1 +
> >   4 files changed, 651 insertions(+)
> >   create mode 100644 tests/gem_ctx_freq.c
> > 
> 
> [snip]
> 
> > +static void check_invalid(int fd, uint32_t ctx, uint32_t min, uint32_t max)
> > +{
> > +     const struct test {
> > +             uint32_t min, max;
> > +     } tests[] = {
> > +             { min - 50, max - 50 },
> > +             { min - 50, max },
> > +             { min - 50, max + 50 },
> > +             { min, max + 50 },
> > +             { min + 50, max + 50 },
> > +
> > +             { min - 50, min - 50 },
> > +
> > +             { min - 50, min },
> > +             { min + 50, min },
> > +             { min, min - 50 },
> > +
> > +             { max + 50, max },
> > +             { max, max + 50 },
> > +             { max, max - 50 },
> > +
> > +             { max + 50, max + 50 },
> 
> Is unprivileged "{ max, max }" allowed? In other words pin to max 
> frequency by anyone? If so, what happens when all userspace learns about 
> this and wants to use it just so to be lower latency than the other guy?

I've gone with allow, since (a) it's always constrained by the global
user imposed limit and (b) userspace can already keep the gpu at max
frequency by load. At the start I opined that only CAP_SYS_NICE would be
allowed to raise the frequency bounds, but realised that in practice it
is immaterial as they were already running at max frequency anyway.

/*
 * As we constrain the frequency request from the
 * context (application) by the sysadmin imposed limits,
 * it is reasonable to allow the application to
 * specify its preferred range within those limits.
 * That is we do not need to restrict requesting
 * a higher frequency to privileged (CAP_SYS_NICE)
 * processes.
 */

> Or even on our integrated graphics, such userspace would unwisely take 
> away power budget from the CPU. Or could it even harm itself by 
> triggering too much thermal throttling and run slower than if it let the 
> balance be controlled by the system?

It will indeed. Running at max frequency is not a sensible idea for
anything but a few applications (dare we say miners? ;). I thought
compositors might benefit from reduced latency by starting at max,
https://bugs.freedesktop.org/show_bug.cgi?id=102199
but realistically they care more about power consumption and gain most of
the latency reduction from priority sorting and preemption.

On the bright side, we give them a loaded gun with which they can shoot
both feet off. They have to be confident that they do know their
behaviour better than the hw (which for a few will be true). We give
them the means to do so, we do not say it is wise.

> Or will this be tied with the cgroup work to allow only clients allowed 
> by sysadmin to do this?

That's what I think as well. I think we will end up with everything that
can be adjusted via CONTEXT_SETPARAM will be constrained by cgroup.

Once again, we can only look at the integration of schedfreq and CFS as
being the direction the GPUs will also eventually take.
-Chris