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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 3 Sep 2020 10:38:58 -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 9:04 AM Sai Prakash Ranjan
<saiprakash.ranjan@...eaurora.org> wrote:
>
> Hi,
>
> On 2020-09-03 21:24, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Sep 3, 2020 at 8:47 AM Sai Prakash Ranjan
> > <saiprakash.ranjan@...eaurora.org> wrote:
> >>
> >> On 2020-09-03 19:16, Doug Anderson wrote:
> >> > 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.
> >> >
> >>
> >> The retention setting is based on sub cache id(SCID), so I think its
> >> for
> >> runtime pm, the power numbers weren't provided. But I believe these
> >> decisions are made after solid testing and not some random
> >> approximations.
> >
> > Right, I believe it was tested, I just wonder if it was tested on a
> > phone vs. a laptop.  A phone is almost constantly waking up to deal
> > with stuff (which is why my phone battery barely lasts till the end of
> > the day).  Phones also usually have some type of self refresh on their
> > panels so they can be suspended even when they look awake which means
> > even more constant wakeups.  A laptop (especially without panel self
> > refresh) may have very different usage models.  I'm trying to confirm
> > that this setting is appropriate for both classes of devices or if it
> > has been only measured / optimized for the cell phone use case.
> >
>
> Could be, but there are windows laptops based on QCOM SoCs where these
> must have also been tested (note that this setting can also be in
> firmware
> and no one would know), but I don't have numbers to quantify.

OK, fair enough.  Thanks for the discussion.  I'm good with a somewhat
broad explanation in the commit message then and if we find that this
somehow affects power numbers in a bad way we can track down further.

-Doug