Improving idle behavior in tickless systems [LWN.net]

Improving idle behavior in tickless systems

Posted Dec 31, 2018 21:24 UTC (Mon) by rweikusat2 (subscriber, #117920)
In reply to: Improving idle behavior in tickless systems by Paf
Parent article: Improving idle behavior in tickless systems

The article contained the following statement:

Devices cause interrupts at (more or less) predictable intervals that depend on the applications that are running; a cpuidle governor can measure these intervals to make predictions for when the next device interrupt will occur.

And this is simply not true. A NIC will generate interrupts in response to uncontrollable, external events for both sending and receiving. The same is true for any other kind of interrupt-using device not driven by the computer itself. As I already wrote, the very reason interrupts exist is to notify a CPU of some unpredictable change in state which needs to be handled now (or as close to now as possible) regardless of whatever else the CPU happened to be doing at the time of the event.

The code also doesn't even try to "predict" anything. After heuristically selecting some idle state based on the time until the next timer event, it compares the length of the last 8 idle periods against the 'target residency' of the selected state (in a seriously contorted way, BTW) and if more than half of them were smaller, selects a different idle state (simplification).

to post comments

Improving idle behavior in tickless systems

Posted Dec 31, 2018 21:37 UTC (Mon) by corbet (editor, #1) [Link] (2 responses)

I'm sorry, but I think you're trying a little too hard here.

An individual interrupt is not predictable, but, as with the weather, a prediction that "things will happen in the future much like they have in the recent past" is relatively likely to be true. Interrupts are not quantum events, they are the result of the workload and the environment that the system is in. So there is value in a heuristic that looks at residency times and predicts that something similar will happen next.

Perhaps it's time to give this a rest?

Improving idle behavior in tickless systems

Posted Dec 31, 2018 21:46 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

The code still doesn't and cannot predict device interrupts. That's something the article simply got wrong. Some part of it is based on the assumption that an idle state shouldn't be used if more than 4 of the last 8 measured idle periods were shorter than its so-called target residency. There doesn't seem to be any published rationale for this design and small powers of 2 always raise the suspicion of someone picking a number from a hat.

This may well be a sensible heuristic but a heuristic it remains --- no fortune telling aka "prediction" involved.

Improving idle behavior in tickless systems

Posted Dec 31, 2018 23:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> This may well be a sensible heuristic but a heuristic it remains --- no fortune telling aka "prediction" involved.

Prediction != fortune telling. There are multiple meanings for the same word.

https://www.merriam-webster.com/dictionary/prediction

One of them is forecast which is defined as

"to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data"

Improving idle behavior in tickless systems

Posted Jan 2, 2019 7:33 UTC (Wed) by flussence (guest, #85566) [Link]

>And this is simply not true. A NIC will generate interrupts in response to uncontrollable, external events for both sending and receiving. The same is true for any other kind of interrupt-using device not driven by the computer itself.
Input devices are some of the most predictable, actually. A pointer interrupt is statistically almost certain to be followed by another (thanks to Newton's laws of physics), and at regularly spaced intervals (grep MOUSE_DPI /lib/udev/hwdb.d/70-mouse.hwdb). A keyboard key down event is often followed by a corresponding key up a few milliseconds later, or some action on a known timeout.

Strong assumptions can also be made about network interrupts due to the earliest departure time queueing algorithm, wifi packet intervals, characteristics of low-spec consumer ISP hardware, timer quantization everywhere else in the stack. I just left wireshark open for a minute and saw several flows with regularly spaced packets.

Algorithmically generated inputs are really not good sources of entropy, if they were servers wouldn't need hardware RNGs.