From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Stephen Boyd <swboyd@chromium.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Isaac J. Manjarres" <isaacm@codeaurora.org>,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers
Date: Thu, 03 Sep 2020 15:28:32 +0530 [thread overview]
Message-ID: <7714ee57f75542839d5c33b28f232aa6@codeaurora.org> (raw)
In-Reply-To: <d949bdfa15b133f74a47727401553c76@codeaurora.org>
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.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2020-09-03 9:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 14:47 [PATCHv2] soc: qcom: llcc: Support chipsets that can write to llcc registers Sai Prakash Ranjan
2020-08-17 21:05 ` Doug Anderson
2020-08-18 9:40 ` Sai Prakash Ranjan
2020-08-18 15:12 ` Doug Anderson
2020-08-18 15:37 ` Sai Prakash Ranjan
2020-09-03 9:58 ` Sai Prakash Ranjan [this message]
2020-09-03 13:46 ` Doug Anderson
2020-09-03 15:47 ` Sai Prakash Ranjan
2020-09-03 15:54 ` Doug Anderson
2020-09-03 16:04 ` Sai Prakash Ranjan
2020-09-03 17:38 ` Doug Anderson
2020-09-03 18:11 ` Sai Prakash Ranjan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7714ee57f75542839d5c33b28f232aa6@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=dianders@chromium.org \
--cc=isaacm@codeaurora.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox