[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z2P3bh04xXsreBF7@hovoldconsulting.com>
Date: Thu, 19 Dec 2024 11:37:34 +0100
From: Johan Hovold <johan@...nel.org>
To: Sibi Sankar <quic_sibis@...cinc.com>
Cc: Cristian Marussi <cristian.marussi@....com>, sudeep.holla@....com,
andersson@...nel.org, konrad.dybcio@...aro.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, quic_rgottimu@...cinc.com,
quic_kshivnan@...cinc.com, conor+dt@...nel.org,
arm-scmi@...r.kernel.org,
Ettore Chimenti <ettore.chimenti@...aro.org>
Subject: Re: [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor
Extensions
On Tue, Dec 17, 2024 at 05:19:25PM +0530, Sibi Sankar wrote:
> On 12/5/24 21:22, Johan Hovold wrote:
> > On Thu, Dec 05, 2024 at 04:26:55PM +0530, Sibi Sankar wrote:
> >> On 11/22/24 14:07, Johan Hovold wrote:
> >
> >>> I have a Lenovo ThinkPad T14s set up now so I gave this series a spin
> >>> there too, and there I do *not* see the above mentioned -EOPNOSUPP error
> >>> and the memlat driver probes successfully.
> >>>
> >>> On the other hand, this series seems to have no effect on a kernel
> >>> compilation benchmark. Is that expected?
> >>
> >> I can have a look at your tree. But memlat in general
> >> depends on the cpu frequency when your benchmarks max
> >> the cpu's the ddr/llcc are scaled accordingly by it.
> >
> > A kernel compilation should max out the CPU frequency on all cores.
Answering my own question here; bwmon should scale the buses for
benchmarks like kernel compilations so I guess the non-existing impact
of memlat is expected here.
Ettore helped me run some further benchmarks, including cachebench, but
also saw no positive (or negative) effect with this series running on an
X1E CRD (with recent firmware).
Do you have any suggestions of benchmarks to run where the effect of
memlat should show up? What have you been using for testing?
I did measure a possibly slightly higher (idle) power consumption with
memlat, but I guess that is also expected given the intended more
aggressive ramping of the bus clocks.
These are the branches (and configs; johan_defconfig) we've used for
testing:
https://github.com/jhovold/linux/tree/wip/x1e80100-6.13-rc3
https://github.com/jhovold/linux/tree/wip/x1e80100-6.13-rc3-memlat
> >>> And does this mean that you should stick with the uppercase "MEMLAT"
> >>> string after all? The firmware on my CRD is not the latest one, but I am
> >>> using the latest available firmware for the T14s.
> >>
> >> We should stick with "memlat" if we run into a device in the
> >> wild that doesn't support "MEMLAT"
> >
> > Ok. So the updated firmware supports both strings?
>
> Sry for the delay, was out sick. Yes the updated firmware supports both
> strings.
No worries, hope you're feeling better.
I noticed that the firmware on the T14s indeed accepts both strings.
Johan
Powered by blists - more mailing lists