linux-kernel - Re: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Sep 2020 06:46:30 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Isaac J. Manjarres" <isaacm@...eaurora.org>,
        linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to
 llcc registers

Hi,

On Thu, Sep 3, 2020 at 2:58 AM Sai Prakash Ranjan
<saiprakash.ranjan@...eaurora.org> wrote:
>
> Hi,
>
> On 2020-08-18 21:07, Sai Prakash Ranjan wrote:
> > Hi Doug,
> >
> >>
> >> I guess to start, it wasn't obvious (to me) that there were two
> >> choices and we were picking one.  Mentioning that the other
> >> alternative was way-based allocation would help a lot.  Even if you
> >> can't fully explain the differences between the two, adding something
> >> to the commit message indicating that this is a policy decision (in
> >> other words, both work but each have their tradeoffs) would help.
> >> Something like this, if it's correct:
> >>
> >> In general we try to enable capacity based allocation (instead of the
> >> default way based allocation) since that gives us better performance
> >> with the current software / hardware configuration.
> >>
> >
> > Thanks, I will add it for next version. Let me also go poke some arch
> > teams
> > to understand if we actually do gain something with this selection, who
> > knows
> > we might get some additional details as well.
> >
>
> I got some information from arch team today, to quote them exactly:
>
> 1) What benefits capacity based allocation brings over the default way
> based allocation?
>
> "Capacity based allows finer grain partition. It is not about improved
> performance but more flexibility in configuration."
>
> 2) Retain through power collapse, doesn’t it burn more power?
>
> "This feature is similar to the standard feature of retention. Yes, when
> we
> have cache in retention mode it burns more power but it keeps the values
> so
> that when we wake up we can get more cache hits."
>
>
> If its good enough, then I will add this info to the commit msg and post
> next version.

Sounds fine to me.  I was mostly looking for a high level idea of what
was happening here.  I am at least a little curious about the
retention bit.  Is that retention during S3, or during some sort of
Runtime PM?  Any idea how much power is burned?  Unless the power is
miniscule it seems hard to believe that it would be a net win to keep
a cache powered up during S3 unless you're planning on waking up a
lot.

-Doug