From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: gautham.shenoy@amd.com, mario.limonciello@amd.com,
perry.yuan@amd.com, ray.huang@amd.com, viresh.kumar@linaro.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] cpufreq: Add a callback to update the min_freq_req from drivers
Date: Tue, 8 Oct 2024 12:02:30 +0530 [thread overview]
Message-ID: <b4758500-9169-41fd-8dc4-9b61d00f2fb6@amd.com> (raw)
In-Reply-To: <CAJZ5v0j46anSdQBnsqojcyn2RGKG259ahd92n380wUSAtRFDxg@mail.gmail.com>
Hello Rafael,
On 10/7/2024 9:18 PM, Rafael J. Wysocki wrote:
> On Mon, Oct 7, 2024 at 5:46 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>>
>> Hi,
>>
>> On Mon, Oct 7, 2024 at 6:40 AM Dhananjay Ugwekar
>> <Dhananjay.Ugwekar@amd.com> wrote:
>>>
>>> Hello Rafael,
>>>
>>> On 10/4/2024 11:47 PM, Rafael J. Wysocki wrote:
>>>> On Thu, Oct 3, 2024 at 10:44 AM Dhananjay Ugwekar
>>>> <Dhananjay.Ugwekar@amd.com> wrote:
>>>>>
>>>>> Currently, there is no proper way to update the initial lower frequency
>>>>> limit from cpufreq drivers.
>>>>
>>>> Why do you want to do it?
>>>
>>> We want to set the initial lower frequency limit at a more efficient level
>>> (lowest_nonlinear_freq) than the lowest frequency, which helps save power in
>>> some idle scenarios, and also improves benchmark results in some scenarios.
>>> At the same time, we want to allow the user to set the lower limit back to
>>> the inefficient lowest frequency.
>>
>> So you want the default value of scaling_min_freq to be greater than
>> the total floor.
Yes, we want to set the default min value to what we think is best for the platform.
>>
>> I have to say that I'm not particularly fond of this approach because
>> it is adding a new meaning to scaling_min_freq: Setting it below the
>> default would not cause the driver to use inefficient frequencies
>
> s/not/now/ (sorry)
I believe we are not changing the meaning of the scaling_min_freq just setting it
to the best value at boot and then allowing the user to have access to the entire
frequency range for the platform. Also, we have cpuinfo_min_freq/max_freq to
indicate to the user as to what the entire frequency range is for the platform
(depending on boost enabled/disabled).
>
> I should have double checked this before sending.
>
>> which user space may not be aware of.
I guess, this part we can fix by documenting correctly ?
>> Moreover, it would tell the
>> driver how far it could go with that.
Sorry, I didnt understand this part.
>>
>> IMV it would be bettwr to have a separate interface for this kind of tuning.
I feel like we can incorporate this change cleanly enough into scaling_min_freq,
without adding a new interface which might further confuse the user. But please
let me know your concerns and thoughts.
Thanks,
Dhananjay
next prev parent reply other threads:[~2024-10-08 6:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 8:39 [PATCH 0/3] cpufreq/amd-pstate: Set initial min_freq to lowest_nonlinear_freq Dhananjay Ugwekar
2024-10-03 8:39 ` [PATCH 1/3] cpufreq: Add a callback to update the min_freq_req from drivers Dhananjay Ugwekar
2024-10-04 6:41 ` Gautham R. Shenoy
2024-10-04 18:17 ` Rafael J. Wysocki
2024-10-07 4:40 ` Dhananjay Ugwekar
2024-10-07 15:46 ` Rafael J. Wysocki
2024-10-07 15:48 ` Rafael J. Wysocki
2024-10-08 6:32 ` Dhananjay Ugwekar [this message]
2024-10-10 17:57 ` Rafael J. Wysocki
2024-10-10 7:35 ` Viresh Kumar
2024-10-10 9:54 ` Dhananjay Ugwekar
2024-10-10 10:07 ` Viresh Kumar
2024-10-03 8:39 ` [PATCH 2/3] cpufreq/amd-pstate: Set the initial min_freq to lowest_nonlinear_freq Dhananjay Ugwekar
2024-10-04 8:47 ` Gautham R. Shenoy
2024-10-03 8:39 ` [PATCH 3/3] cpufreq/amd-pstate: Cleanup the old min_freq qos request remnants Dhananjay Ugwekar
2024-10-03 19:23 ` [PATCH 0/3] cpufreq/amd-pstate: Set initial min_freq to lowest_nonlinear_freq Mario Limonciello
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=b4758500-9169-41fd-8dc4-9b61d00f2fb6@amd.com \
--to=dhananjay.ugwekar@amd.com \
--cc=gautham.shenoy@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=perry.yuan@amd.com \
--cc=rafael@kernel.org \
--cc=ray.huang@amd.com \
--cc=viresh.kumar@linaro.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
all inboxes | Powered by JetHome®