All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thara Gopinath <thara.gopinath@linaro.org>
To: Quentin Perret <qperret@google.com>
Cc: mingo@redhat.com, peterz@infradead.org, ionela.voinescu@arm.com,
	vincent.guittot@linaro.org, rui.zhang@intel.com,
	edubezval@gmail.com, linux-kernel@vger.kernel.org,
	amit.kachhap@gmail.com, javi.merino@kernel.org,
	daniel.lezcano@linaro.org, kernel-team@android.com
Subject: Re: [Patch v3 7/7] sched: thermal: Enable tuning of decay period
Date: Tue, 22 Oct 2019 16:36:13 -0400	[thread overview]
Message-ID: <5DAF683D.60003@linaro.org> (raw)
In-Reply-To: <20191022090334.GA85349@google.com>

On 10/22/2019 05:03 AM, Quentin Perret wrote:
> Hi Thara,
> 
> On Monday 21 Oct 2019 at 17:03:56 (-0400), Thara Gopinath wrote:
>> On 10/15/2019 06:14 AM, Quentin Perret wrote:
>>> Hi Thara,
>>>
>>> On Sunday 13 Oct 2019 at 20:58:25 (-0400), Thara Gopinath wrote:
>>>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>>>> index 00fcea2..5056c08 100644
>>>> --- a/kernel/sysctl.c
>>>> +++ b/kernel/sysctl.c
>>>> @@ -376,6 +376,13 @@ static struct ctl_table kern_table[] = {
>>>>  		.mode		= 0644,
>>>>  		.proc_handler	= proc_dointvec,
>>>>  	},
>>>> +	{
>>>> +		.procname	= "sched_thermal_decay_coeff",
>>>> +		.data		= &sysctl_sched_thermal_decay_coeff,
>>>> +		.maxlen		= sizeof(unsigned int),
>>>> +		.mode		= 0644,
>>>> +		.proc_handler	= proc_dointvec,
>>>
>>> Perhaps change this for 'sched_proc_update_handler' with min and max
>>> values ? Otherwise userspace is allowed to write nonsensical values
>>> here. And since sysctl_sched_thermal_decay_coeff is used to shift, this
>>> can lead to an undefined behaviour.
>> Will do
>>>
>>> Also, could we take this sysctl out of SCHED_DEBUG ? I expect this to be
>>> used/tuned on production devices where SCHED_DEBUG should theoretically
>>> be off.
>>
>> I will take it out of SCHED_DEBUG. I am wondering if this should be
>> a runtime control at all. Because this is a shift this changes the
>> accumulating window for the thermal pressure signal. A runtime change
>> will not guarantee a clean start of the window. May be I should make
>> this a config option.
> 
> I'd personally prefer if it wan't a Kconfig option. We'd like to make
> Android devices (which are going to use this) work with a Generic Kernel
> Image, which means there will be a single config for everyone. But I
> expect this knob to be tuned to different values depending on the SoC.
> 
> If you really don't want a sysctl, perhaps a cmdline option could work ?
yes . I will. I have sent across v4 with these and other review comments
fixed.
> 
> Thanks,
> Quentin
> 


-- 
Warm Regards
Thara

      reply	other threads:[~2019-10-22 20:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-14  0:58 [Patch v3 0/7] Introduce Thermal Pressure Thara Gopinath
2019-10-14  0:58 ` [Patch v3 1/7] sched/pelt.c: Add support to track thermal pressure Thara Gopinath
2019-10-14 13:55   ` Vincent Guittot
2019-10-16 21:15     ` Thara Gopinath
2019-10-14  0:58 ` [Patch v3 2/7] sched: Add infrastructure to store and update instantaneous " Thara Gopinath
2019-10-14 15:50   ` Vincent Guittot
2019-10-16 21:22     ` Thara Gopinath
2019-10-17  8:44       ` Vincent Guittot
2019-10-17 16:40         ` Thara Gopinath
2019-10-18  8:05           ` Vincent Guittot
2019-10-14  0:58 ` [Patch v3 3/7] sched: Initialize per cpu thermal pressure structure Thara Gopinath
2019-10-14  0:58 ` [Patch v3 4/7] sched/fair: Enable CFS periodic tick to update thermal pressure Thara Gopinath
2019-10-14  0:58 ` [Patch v3 5/7] sched/fair: update cpu_capcity to reflect " Thara Gopinath
2019-10-14  0:58 ` [Patch v3 6/7] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-10-14  0:58 ` [Patch v3 7/7] sched: thermal: Enable tuning of decay period Thara Gopinath
2019-10-15 10:14   ` Quentin Perret
2019-10-21 21:03     ` Thara Gopinath
2019-10-22  9:03       ` Quentin Perret
2019-10-22 20:36         ` Thara Gopinath [this message]

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=5DAF683D.60003@linaro.org \
    --to=thara.gopinath@linaro.org \
    --cc=amit.kachhap@gmail.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=edubezval@gmail.com \
    --cc=ionela.voinescu@arm.com \
    --cc=javi.merino@kernel.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rui.zhang@intel.com \
    --cc=vincent.guittot@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.