On 01/23/2017 08:50 PM, Daniel Lezcano wrote:
> On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
>>
>>> Yeah, that could be problematic. The code snippet gives the general idea
>>> but it
>>> could be changed by for example by a flag telling the cpus when they enter
>>> idle
>>> to upd
On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
>
> >Yeah, that could be problematic. The code snippet gives the general idea but
> >it
> >could be changed by for example by a flag telling the cpus when they enter
> >idle
> >to update their state_count. Or something like that.
>
> Yes
Yeah, that could be problematic. The code snippet gives the general idea but it
could be changed by for example by a flag telling the cpus when they enter idle
to update their state_count. Or something like that.
Yes, this idea could be helpful.
But since the idle path isn't a hot path. and a
On Thu, Jan 19, 2017 at 10:43:23PM +0100, Rafael J. Wysocki wrote:
[ ... ]
> > This function is called from the notifier callback:
> >
> > static int cpuidle_latency_notify(struct notifier_block *b,
> > unsigned long l, void *v)
> > {
> > - wake_up_all_idle_cpus();
> > +
On 01/20/2017 05:43 AM, Rafael J. Wysocki wrote:
> The above may be problematic if the constraints change relatively
> often. It is global and it will affect all of the CPUs in the system
> every time and now think about systems with hundreds of them.
Yes, the disadvantage is waking up all idle
On Thu, Jan 19, 2017 at 11:21 AM, Daniel Lezcano
wrote:
> On Thu, Jan 19, 2017 at 05:25:37PM +0800, Alex Shi wrote:
>>
>> > That said, I have the feeling that is taking the wrong direction. Each
>> > time we
>> > are entering idle, we check the latencies. Entering idle can be done
>> > thousand
On Thu, Jan 19, 2017 at 05:25:37PM +0800, Alex Shi wrote:
>
> > That said, I have the feeling that is taking the wrong direction. Each time
> > we
> > are entering idle, we check the latencies. Entering idle can be done
> > thousand
> > of times per second. Wouldn't make sense to disable the sta
> That said, I have the feeling that is taking the wrong direction. Each time we
> are entering idle, we check the latencies. Entering idle can be done thousand
> of times per second. Wouldn't make sense to disable the states not fulfilling
> the constraints at the moment the latencies are changed
On Thu, Jan 12, 2017 at 09:27:04PM +0800, Alex Shi wrote:
> Kernel or user may have special requirement on cpu response time, like
> if a interrupt is pinned to a cpu, we don't want the cpu goes too deep
> sleep. This patch can prevent this thing happen by consider per cpu
> resume_latency setting
Thanks a lot, Rik!
Anyone like to give more comments or pick it up?
Regards
Alex
On 01/13/2017 04:03 AM, Rik van Riel wrote:
> Acked-by: Rik van Riel
On Thu, 2017-01-12 at 21:27 +0800, Alex Shi wrote:
> Kernel or user may have special requirement on cpu response time,
> like
> if a interrupt is pinned to a cpu, we don't want the cpu goes too
> deep
> sleep. This patch can prevent this thing happen by consider per cpu
> resume_latency setting in
11 matches
Mail list logo
