This patch series add support for loadavg values for GPU
sub-components. I am adding a SMA algorithm as I was not
really sure if EWMA would be a good fit for this use case.
Changes v2:
- Addressed feedback from Lucas
Christian Gmeiner (4):
drm/etnaviv: add simple moving average (SMA)
drm/etnaviv: add loadavg accounting
drm/etnaviv: show loadavg in debugfs
drm/etnaviv: export loadavg via perfmon
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 14 ++++
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 76 +++++++++++++++++++++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 37 +++++++++++
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++++++++++++++++++++++
drivers/gpu/drm/etnaviv/etnaviv_sma.h | 53 +++++++++++++++
5 files changed, 257 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_sma.h
--
2.36.1
Make it possible to access the sub-GPU component load value from
user space with the perfmon infrastructure.
Signed-off-by: Christian Gmeiner <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index bafdfe49c1d8..d65d9af3a74a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -120,6 +120,19 @@ static u32 hi_total_idle_cycle_read(struct etnaviv_gpu *gpu,
return gpu_read(gpu, reg);
}
+static u32 load_read(struct etnaviv_gpu *gpu,
+ const struct etnaviv_pm_domain *domain,
+ const struct etnaviv_pm_signal *signal)
+{
+ u32 load;
+
+ spin_lock_bh(&gpu->loadavg_spinlock);
+ load = gpu->loadavg_percentage[signal->data];
+ spin_unlock_bh(&gpu->loadavg_spinlock);
+
+ return load;
+}
+
static const struct etnaviv_pm_domain doms_3d[] = {
{
.name = "HI",
@@ -419,6 +432,72 @@ static const struct etnaviv_pm_domain doms_3d[] = {
&perf_reg_read
}
}
+ },
+ {
+ .name = "LOAD",
+ .nr_signals = 12,
+ .signal = (const struct etnaviv_pm_signal[]) {
+ {
+ "FE",
+ 0,
+ &load_read
+ },
+ {
+ "DE",
+ 1,
+ &load_read
+ },
+ {
+ "PE",
+ 2,
+ &load_read
+ },
+ {
+ "SH",
+ 3,
+ &load_read
+ },
+ {
+ "PA",
+ 4,
+ &load_read
+ },
+ {
+ "SE",
+ 5,
+ &load_read
+ },
+ {
+ "RA",
+ 6,
+ &load_read
+ },
+ {
+ "TX",
+ 7,
+ &load_read
+ },
+ {
+ "VG",
+ 8,
+ &load_read
+ },
+ {
+ "IM",
+ 9,
+ &load_read
+ },
+ {
+ "FP",
+ 10,
+ &load_read
+ },
+ {
+ "TS",
+ 11,
+ &load_read
+ }
+ }
}
};
--
2.36.1
Am Dienstag, dem 21.06.2022 um 09:20 +0200 schrieb Christian Gmeiner:
> Make it possible to access the sub-GPU component load value from
> user space with the perfmon infrastructure.
>
You need to explain a bit more how you intend to use those.
Contrary to all other perfmon values, where we go to great lengths to
only count the load put onto the GPU by the specific process requesting
the perfmon, the loadavg values also include the load caused by other
submits. Due to this difference in behavior I fear that those new
counters might be confusing to use. But maybe you have a use-case in
mind that I don't see right now.
Regards,
Lucas
> Signed-off-by: Christian Gmeiner <[email protected]>
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 79 +++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index bafdfe49c1d8..d65d9af3a74a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -120,6 +120,19 @@ static u32 hi_total_idle_cycle_read(struct etnaviv_gpu *gpu,
> return gpu_read(gpu, reg);
> }
>
> +static u32 load_read(struct etnaviv_gpu *gpu,
> + const struct etnaviv_pm_domain *domain,
> + const struct etnaviv_pm_signal *signal)
> +{
> + u32 load;
> +
> + spin_lock_bh(&gpu->loadavg_spinlock);
> + load = gpu->loadavg_percentage[signal->data];
> + spin_unlock_bh(&gpu->loadavg_spinlock);
> +
> + return load;
> +}
> +
> static const struct etnaviv_pm_domain doms_3d[] = {
> {
> .name = "HI",
> @@ -419,6 +432,72 @@ static const struct etnaviv_pm_domain doms_3d[] = {
> &perf_reg_read
> }
> }
> + },
> + {
> + .name = "LOAD",
> + .nr_signals = 12,
> + .signal = (const struct etnaviv_pm_signal[]) {
> + {
> + "FE",
> + 0,
> + &load_read
> + },
> + {
> + "DE",
> + 1,
> + &load_read
> + },
> + {
> + "PE",
> + 2,
> + &load_read
> + },
> + {
> + "SH",
> + 3,
> + &load_read
> + },
> + {
> + "PA",
> + 4,
> + &load_read
> + },
> + {
> + "SE",
> + 5,
> + &load_read
> + },
> + {
> + "RA",
> + 6,
> + &load_read
> + },
> + {
> + "TX",
> + 7,
> + &load_read
> + },
> + {
> + "VG",
> + 8,
> + &load_read
> + },
> + {
> + "IM",
> + 9,
> + &load_read
> + },
> + {
> + "FP",
> + 10,
> + &load_read
> + },
> + {
> + "TS",
> + 11,
> + &load_read
> + }
> + }
> }
> };
>
Hi Lucas
> You need to explain a bit more how you intend to use those.
>
> Contrary to all other perfmon values, where we go to great lengths to
> only count the load put onto the GPU by the specific process requesting
> the perfmon, the loadavg values also include the load caused by other
> submits. Due to this difference in behavior I fear that those new
> counters might be confusing to use. But maybe you have a use-case in
> mind that I don't see right now.
I see these values as total load avg of a sub-GPU component. Sure it is not per
process but it is a starting point. I have no problem introducing per
process load avg
values .. lets see how the next version of this series will look like,
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy