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 <ch...@chris-wilson.co.uk>
Cc: Paneri, Praveen <praveen.pan...@intel.com>
Cc: Kamble, Sagar A <sagar.a.kam...@intel.com>
Cc: Antonio Argenziano <antonio.argenzi...@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?
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?
Or will this be tied with the cgroup work to allow only clients allowed
by sysadmin to do this?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
