Tuukka,
I've reproduced this negative on a 48 thread 2-socket Xeon during boot
(seen it only once, so far).
expected_us gets calculated to be -1, which is truthful, since the
next timer return value was about 500ns in the past
and our math truncates. This, in turn, confuses the heck out of
menu's
Hi,
On 6 March 2014 09:41, Len Brown wrote:
>
> On Mon, Feb 24, 2014 at 1:29 AM, Tuukka Tikkanen
> wrote:
> > Sometimes (fairly often) when the cpuidle menu governor is making a decision
> > about idle state to enter the next timer for the cpu appears to expire in
> > the past. The menu governor
NAK
tick_nohz_get_sleep_length() has exactly 1 consumer -- cpuidle.
Rather than have cpuidle second guess what is returned,
tick_nohz_get_sleep_length() should be updated to return a value
that makes sense to cpuidle.
thanks,
Len Brown, Intel Open Source Technology Cent
--
To unsubscribe from th
On Mon, Feb 24, 2014 at 1:29 AM, Tuukka Tikkanen
wrote:
> Sometimes (fairly often) when the cpuidle menu governor is making a decision
> about idle state to enter the next timer for the cpu appears to expire in
> the past. The menu governor expects the expiry to always be in the future
> and in fa
On Monday, February 24, 2014 12:05:39 PM Nicolas Pitre wrote:
> On Mon, 24 Feb 2014, Tuukka Tikkanen wrote:
>
> > Sometimes (fairly often) when the cpuidle menu governor is making a decision
> > about idle state to enter the next timer for the cpu appears to expire in
> > the past. The menu govern
On Mon, 24 Feb 2014, Tuukka Tikkanen wrote:
> Sometimes (fairly often) when the cpuidle menu governor is making a decision
> about idle state to enter the next timer for the cpu appears to expire in
> the past. The menu governor expects the expiry to always be in the future
> and in fact stores th
6 matches
Mail list logo
