However my fundamental concerns about the policy whether to disable the sched
tick remain:
Mixing the precise timer and vague heuristic for the decision is
dangerous. The timer should not be wrong, heuristic may be.
Well, I wouldn't say "dangerous". It may be suboptimal, but even that is not
a
On Wednesday, March 28, 2018 11:14:36 AM CEST Thomas Ilsche wrote:
> On 2018-03-22 18:40, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Add a new pointer argument to cpuidle_select() and to the ->select
> > cpuidle governor callback to allow a boolean value indicating
> > whether o
On 2018-03-22 18:40, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
Add a new pointer argument to cpuidle_select() and to the ->select
cpuidle governor callback to allow a boolean value indicating
whether or not the tick should be stopped before entering the
selected state to be returned from
On 2018.03.22 10:40 Rafael J. Wysocki wrote:
...[snip]...
>The difference between this and the original v7 (of patch [5/8]) is
> what happens in menu_update(). This time next_timer_us is checked
> properly and if that is above the tick boundary and a tick wakeup occurs,
> the function simply set
4 matches
Mail list logo
