[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180608044839.eyaib5gkbw7biu2a@vireshk-i7>
Date: Fri, 8 Jun 2018 10:18:39 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Daniel Lezcano <daniel.lezcano@...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 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.
--
viresh
Powered by blists - more mailing lists