lkml.org 
[lkml]   [2020]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers
On 2020-09-03 23:08, Doug Anderson wrote:
> Hi,
>
> On Thu, Sep 3, 2020 at 9:04 AM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.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@codeaurora.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@codeaurora.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.
>

Thanks, I agree that we should keep an eye in case of any fluctuations
in power numbers.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation

\
 
 \ /
  Last update: 2020-09-03 20:12    [W:0.061 / U:2.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site