LWN: Comments on "Letting sleeping processors lie"

Letting sleeping processors lie

brouhaha — 2003-11-13T09:29:30+00:00

Good explanation, thanks. I should have been less hasty to complain.

Letting sleeping processors lie

georgeanz — 2003-10-23T23:27:48+00:00

The "tick less" system was put together with instrumentation and proved to be overload prone. The problem is that entry and removal of one (or more) timers is required each context switch to keep track of the time slice and process time limits. This overhead increases as the load (i.e number of context switches per second) increases and was shown to cross over the flat overhead of a normal ticking system as a relatively low load.

Thus, since we really want less overhead with increasing load, and never more, I rejected the "tick less" system.

The VST code, on the other hand, fades away when the system is busy and only takes from idle time to do its thing.

I still have the "tick less" system patch on source forge for those who what to look at this in more detail. See: http://sourceforge.net/projects/high-res-timers/

Letting sleeping processors lie

giraffedata — 2003-10-18T21:08:56+00:00

Well, for one thing the patch described there is for IBM Z processors (aka S/360, S/370, S/390, et al) only. It exploits the fact that the Z has a full precision, fully accurate real time clock integrated into the CPU. Most systems on which Linux runs do not have that. They have a decrepit ISA clock that will tell you the curent time within a second, and gain or lose a few seconds a week. And it takes I/O to query it.

Letting sleeping processors lie

brouhaha — 2003-10-16T20:58:27+00:00

How is this better than the earlier "no-tick" patches by Martin Schwidefsky, which were described in the Kernel section of the 12-APR-2001 issue of LWM under the heading "No more jiffies?"

Eliminating jiffies entirely seems a lot cleaner than VST. "No-tick" was rejected by the same Mr. Anzinger that is now pushing VST, on the basis that "no-tick" imposed extra overhead, yet VST seems to have exactly the same overhead for a less significant degree of benefit.

Thirty months later, I would have expected something better. Sigh.

2.4 vs 2.6

ncm — 2003-10-16T02:57:51+00:00

It seems worth noting, as a matter of course, whether a given patch is meant for the 2.4 or 2.6 kernel series. This one applies to 2.4, but of course will be ported to 2.6 someday.

Letting sleeping processors lie

jdike — 2003-10-16T01:49:42+00:00

This feature is also highly desired by virtual machine people, i.e. UML and S/390. The reason is that a bunch of 1000 HZ VMs on a host generate 1000 timer interrupts per second per virtual machine. This is useless work for the host, and quickly adds up to a noticable load.

Virtual machines would use VST by delaying the next timer from the host until they actually have something to do for that tick. So, an idle virtual machine would consume no host CPU.

Jeff