Messages in this thread | | | Date | Thu, 03 Sep 2020 21:17:35 +0530 | From | Sai Prakash Ranjan <> | Subject | Re: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers |
| |
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.
Thanks, Sai
-- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
| |