lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CA+0soA=9D6Rj9Z_3P58dFQB7ZkZooEfjKgpVeAVtoAHJ8MVfsA@mail.gmail.com>
Date:   Fri, 14 Aug 2020 12:25:24 -0700
From:   Peiyong Lin <lpy@...gle.com>
To:     Chris Wilson <chris@...is-wilson.co.uk>,
        Sidath Senanayake <sidaths@...gle.com>, zzyiwei@...roid.com
Cc:     Amit Kucheria <amit.kucheria@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ingo Molnar <mingo@...hat.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Pavel Machek <pavel@....cz>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-kernel@...r.kernel.org,
        Prahlad Kilambi <prahladk@...gle.com>,
        android-kernel@...gle.com
Subject: Re: [PATCH] Add power/gpu_frequency tracepoint.

Hi Chris, please see my comments inline.


On Fri, Aug 14, 2020 at 8:22 AM Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> Quoting Peiyong Lin (2020-08-13 22:03:57)
> > Historically there is no common trace event for GPU frequency, in
> > downstream Android each different hardware vendor implements their own
> > way to expose GPU frequency, for example as a debugfs node.  This patch
> > standardize it as a common trace event in upstream linux kernel to help
> > the ecosystem have a common implementation across hardware vendors.
> > Toolings in the Linux ecosystem will benefit from this especially in the
> > downstream Android, where this information is critical to graphics
> > developers.
> >
> > Signed-off-by: Peiyong Lin <lpy@...gle.com>
> > ---
> >  drivers/gpu/Makefile                    |  1 +
> >  drivers/gpu/trace/Kconfig               |  3 +++
> >  drivers/gpu/trace/Makefile              |  1 +
> >  drivers/gpu/trace/trace_gpu_frequency.c | 13 +++++++++++++
> >  include/trace/events/power.h            | 26 +++++++++++++++++++++++++
> >  5 files changed, 44 insertions(+)
> >  create mode 100644 drivers/gpu/trace/trace_gpu_frequency.c
> >
> > diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> > index 835c88318cec..f289a47eb031 100644
> > --- a/drivers/gpu/Makefile
> > +++ b/drivers/gpu/Makefile
> > @@ -6,3 +6,4 @@ obj-$(CONFIG_TEGRA_HOST1X)      += host1x/
> >  obj-y                  += drm/ vga/
> >  obj-$(CONFIG_IMX_IPUV3_CORE)   += ipu-v3/
> >  obj-$(CONFIG_TRACE_GPU_MEM)            += trace/
> > +obj-$(CONFIG_TRACE_GPU_FREQUENCY)              += trace/
> > diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig
> > index c24e9edd022e..ac4aec8d5845 100644
> > --- a/drivers/gpu/trace/Kconfig
> > +++ b/drivers/gpu/trace/Kconfig
> > @@ -2,3 +2,6 @@
> >
> >  config TRACE_GPU_MEM
> >         bool
> > +
> > +config TRACE_GPU_FREQUENCY
> > +       bool
> > diff --git a/drivers/gpu/trace/Makefile b/drivers/gpu/trace/Makefile
> > index b70fbdc5847f..2b7ae69327d6 100644
> > --- a/drivers/gpu/trace/Makefile
> > +++ b/drivers/gpu/trace/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >
> >  obj-$(CONFIG_TRACE_GPU_MEM) += trace_gpu_mem.o
> > +obj-$(CONFIG_TRACE_GPU_FREQUENCY) += trace_gpu_frequency.o
> > diff --git a/drivers/gpu/trace/trace_gpu_frequency.c b/drivers/gpu/trace/trace_gpu_frequency.c
> > new file mode 100644
> > index 000000000000..f5af5800b52d
> > --- /dev/null
> > +++ b/drivers/gpu/trace/trace_gpu_frequency.c
> > @@ -0,0 +1,13 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * GPU frequency trace points
> > + *
> > + * Copyright (C) 2020 Google, Inc.
> > + */
> > +
> > +#include <linux/module.h>
> > +
> > +#define CREATE_TRACE_POINTS
> > +#include <trace/events/power.h>
> > +
> > +EXPORT_TRACEPOINT_SYMBOL(gpu_frequency);
> > diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> > index af5018aa9517..befc0157131e 100644
> > --- a/include/trace/events/power.h
> > +++ b/include/trace/events/power.h
> > @@ -500,6 +500,32 @@ DEFINE_EVENT(dev_pm_qos_request, dev_pm_qos_remove_request,
> >
> >         TP_ARGS(name, type, new_value)
> >  );
> > +
> > +/**
> > + * gpu_frequency - Reports frequency changes in GPU clock domains
> > + * @state:  New frequency (in KHz)
> > + * @gpu_id: GPU clock domain
> > + */
> > +TRACE_EVENT(gpu_frequency,
> > +
> > +       TP_PROTO(unsigned int state, unsigned int gpu_id),
> > +
> > +       TP_ARGS(state, gpu_id),
> > +
> > +       TP_STRUCT__entry(
> > +               __field(unsigned int, state)
> > +               __field(unsigned int, gpu_id)
>
> What is a gpu-id and how are we supposed to create one?

gpu_id is the id for per GPU clock domain, it should be created for
per GPU clock domain. It's not necessarily tied to a physical GPU.

>
> 'state' is quite non-descript, and since this is not an event template
> you could be a little more specific.
>
> So when should this tracepoint fire? For the frequency change we request,
> or the frequency change of the black box of the pcu?

If an implementation implements this, the GPU frequency tracepoint
should be fired whenever there's a frequency change. That is to say,
when gpu goes from idle to active or vice versa, or when the gpu
frequency goes up and down.

>
> We have found that a tracepoint is not a useful monitor of the actual GPU
> frequencies, for that we use provide sampling via perf-events.
> -Chris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ