linux-kernel - R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <039d01d67f6a$188700d0$49950270$@gmail.com>
Date:   Mon, 31 Aug 2020 09:41:08 +0200
From:   <ansuelsmth@...il.com>
To:     "'Sibi Sankar'" <sibis@...eaurora.org>,
        "'Viresh Kumar'" <viresh.kumar@...aro.org>
Cc:     <vincent.guittot@...aro.org>, <saravanak@...gle.com>,
        "'Sudeep Holla'" <sudeep.holla@....com>,
        "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        "'Rob Herring'" <robh+dt@...nel.org>, <linux-pm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support



> -----Messaggio originale-----
> Da: sibis=codeaurora.org@...codeaurora.org
> <sibis=codeaurora.org@...codeaurora.org> Per conto di Sibi Sankar
> Inviato: lunedì 31 agosto 2020 07:46
> A: Viresh Kumar <viresh.kumar@...aro.org>
> Cc: Ansuel Smith <ansuelsmth@...il.com>; vincent.guittot@...aro.org;
> saravanak@...gle.com; Sudeep Holla <sudeep.holla@....com>; Rafael J.
> Wysocki <rjw@...ysocki.net>; Rob Herring <robh+dt@...nel.org>; linux-
> pm@...r.kernel.org; devicetree@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Oggetto: Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support
> 
> On 2020-08-24 16:10, Viresh Kumar wrote:
> > +Vincent/Saravana/Sibi
> >
> > On 21-08-20, 16:00, Ansuel Smith wrote:
> >> This adds Krait Cache scaling support using the cpufreq notifier.
> >> I have some doubt about where this should be actually placed (clk or
> >> cpufreq)?
> >> Also the original idea was to create a dedicated cpufreq driver (like
> >> it's done in
> >> the codeaurora qcom repo) by copying the cpufreq-dt driver and adding
> >> the cache
> >> scaling logic but i still don't know what is better. Have a very
> >> similar driver or
> >> add a dedicated driver only for the cache using the cpufreq notifier
> >> and do the
> >> scale on every freq transition.
> >> Thanks to everyone who will review or answer these questions.
> >
> > Saravana was doing something with devfreq to solve such issues if I
> > wasn't mistaken.
> >
> > Sibi ?
> 
> IIRC the final plan was to create a devfreq device
> and devfreq-cpufreq based governor to scale them, this
> way one can switch to a different governor if required.

So in this case I should convert this patch to a devfreq driver- 
Isn't overkill to use a governor for such a task?
(3 range based on the cpufreq?)

> (I don't see if ^^ applies well for l2 though). In the
> interim until such a solution is acked on the list we
> just scale the resources directly from the cpufreq

In this case for this SoC we can't really scale the L2 freq
with the cpu since we observed a bug and we need to switch
back to the idle freq sometimes. Also this SoC use the generic
cpufreq-dt driver and doesn't have a dedicated driver. So we
must use a notifier.

> driver. On SDM845/SC7180 SoCs, L3 is modeled as a
> interconnect provider and is directly scaled from the
> cpufreq-hw driver.
> 
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project.