[linuxguy2]

I don't think the two other responders to your question quite have the whole answer so I'm going to chime in. Warning: I'm not a kernel developer, have only read the article and work with linux daily.

To answer your second question, this doesn't have anything to do with disk changes/inotify/etc that a program would use. My understanding is that currently \many\ IO devices respond to the kernel's request for data by triggering an interrupt that then takes time for the kernel to get to for reading. The interrupt process can be a bit slow leading to latency when waiting for the disk to respond. The new system, rather than waiting for an interrupt, continuously checks the driver for new data and as it doesn't rely on an interrupt can achieve far better latency. Lower latency means more operation per second.

With spinning disks who are only able to do <200 operations per second with latencies around 5ms this won't have much of an effect but with SSD who are able to do >2000 operations per second with latencies around 0.5ms trimming off 0.1ms per operation (made that number up) via polling rather than waiting on an interrupt can mean about 20% more operations per second.

[truncate]

I fear, this may impact negatively in terms of power. If I'm not wrong, the point of having interrupts was to save CPU cycles wasted on checking status, i.e. polling. Overall, I think it would be interesting to see some benchmarks on real scenarios.

EDIT: Thinking a bit more about it, interrupts were introduced when CPU were much more slower than they are now. So, the tradeoff I'm thinking isn't that bad.

[wallacoloo]

The power difference may actually be immeasurable, or even an improvement on some systems. Switching from one power state into a lower-power state may actually involve one-time energy payments, which are eventually negated by the power savings as time progresses. In an extreme scenario, a core might power-down its cache to reduce leakage current, which involves sending all of its pending writes onto some bus, which is costly, and then it'll be reading a lot of data back in from elsewhere once it is powered back on as it refills the cache.

In the worst case, you might spend more time and energy switching between power states than you actually spend in a lower power state.

But indeed, it does seem counter-intuitive even with that, as there are often power mode changes available that would pay off in just a few microseconds. It sounds to me like x86 may suffer from a limited IRQ system - there are other systems out there in which IRQ overhead is < 10 cycles.

[mangeletti]

Aha. Very interesting. Thanks so much for taking the time to spell that out for me.