Re: [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 12/19/24 16:07, Johan Hovold wrote:
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.

you would see impact only in cases where you would benefit from
having ddr and llcc at a higher frequency i.e. latency workloads.
I usually run geekbench with and we are expected to see a big
difference with and without it.


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

Thanks, we'll get this sorted out.


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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux