[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <39960620-dc59-92a5-0e57-f00a4d930f7f@linaro.org>
Date: Fri, 8 Jun 2018 10:31:52 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: rjw@...ysocki.net, linux-kernel@...r.kernel.org,
Eduardo Valentin <edubezval@...il.com>,
Javi Merino <javi.merino@...nel.org>,
Leo Yan <leo.yan@...aro.org>,
Kevin Wangtao <kevin.wangtao@...aro.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Rui Zhang <rui.zhang@...el.com>,
Daniel Thompson <daniel.thompson@...aro.org>,
"open list:POWER MANAGEMENT CORE" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH V5] powercap/drivers/idle_injection: Add an idle injection
framework
On 08/06/2018 06:48, Viresh Kumar wrote:
> On 07-06-18, 16:11, Daniel Lezcano wrote:
>>>> I'm wondering if we can have a CPU hotplugged right after the
>>>> 'put_online_cpus', resulting in the 'should park' flag set and then the
>>>> thread goes in the kthread_parkme instead of jumping back the idle
>>>> injection function and decrease the count, leading up to the timer not
>>>> being set again.
>>>
>>> True. That looks like a valid problem to me as well.
>>>
>>> What about starting the hrtimer right from this routine itself, after taking
>>> into account running-time, idle-time, delay, etc ? That would get rid of the
>>> count stuff, this get_online_cpus(), etc.
>>>
>>> Even if we restart the next play-idle cycle a bit early or with some delay, sky
>>> wouldn't fall :)
>>
>> We won't be able to call completion() in this case.
>
> I was just having a look at smpboot.h and saw the park/unpark callbacks. I think
> you can very much use them to align things with CPU hotplug.
Hmm, perhaps. I will have a look at it.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists