Messages in this thread | | | Date | Thu, 03 Sep 2020 23:41:48 +0530 | From | Sai Prakash Ranjan <> | Subject | Re: [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
| |