As far as interval timers are concerned, this is a great example of what I am talking about. The mere fact that you have cyclic interrupts means something is non-ideal from a power-savings point of view; so if the cyclic system is being used at all, something is almost certainly using more power than it should. You might argue that it can’t go away because an interface (BSD and/or POSIX interval timers) promises that functionality will exist, but that’s the point. What if the interface is busted, or shouldn’t exist, or should be used extremely rarely? I can think if a few examples where perfectly exact interval timers are needed — for example, for real-time data collection applications, and servo control — but most of the time, applications don’t need precise interval timers. Yet they may very well end up using that particular interface because nothing better existed at the time.

So to fix these sorts of problems, sometimes you have to change or augment interfaces that had been previously thought of being bedrock. Sometimes it’s not enough to assume that a particular interface is a given, and only try to implement innovations underneath such an interface; instead, you have to somehow innovate around, over, or through a particular interface/abstraction. And yes, sometimes that means trying to find all of the users of that interface, and convincing them to change how they use it.

In terms of the relevance to software engineering in-the-large: remember, I’m not maintaining that deep software engineering is representative of all of software engineering, but rather that the Chandler-esque cock-ups are themselves but one facet of our craft — and not necessarily the most instructive facet.

Finally, as for cyclics, a little contamination would probably do you some good. As John Levon mentioned, the cyclic subsystem is entirely deadline scheduled; if there are no cyclics, there is no interrupt — there is nothing about its design or implementation that is mutually exclusive with the kind of “radical” power savings that you describe. (As background, the design center for the subsystem was to allow arbitrary resolution interval timers, a must-have feature when developing a real-time system. Solaris is used as the basis for quite a few such systems, especially in the defense and telecommunications sectors.)

But all of this serves to remind me that I would have been better off pointing to some subset of the tens-of-thousands of lines of DTrace implementation, for which there exists no Linux analogue to confuse matters.

Furthermore, while my passion is, like yours, involves making the portions of the bedrock that I am responsible as seismically stable as possible, I don’t think it really helps solve the general problem of complex software engineering at the scale of Chandler, Lotus Notes, Microsoft Office, Sun’s Java System Application Server, Tivoli Total Storage Productive Center, and other Very Large Products which include complex UI’s — something which those of us who do OS engineering generally don’t have to worry about much.

Finally, while I’m not particularly interested in getting contaminated, I will argue that if cyclic’s job is to run code on some regular period, such as the HZ heartbeat timer code, this is functionality which is never a good idea if you are truly interested in power saving. In order to get there, code should be woken up when it needs to be, and ideally batched with other code that needs to be woken up at roughly the same time within the permissions given to the timer subsystem regarding accuracy requirements. There should be no reason why a low-level regular heartbeat callback should be called on a system which is trying to save power in a truly radical way. (What? You have a blinking cursor? That should be turned off, or if you must have blinking cursor, it should blink at the same time as all other blinking UI elements. The former is still preferable, though!

(List append)
[] ++ ys = ys
(x:xs) ++ ys = x : (xs ++ ys)

map f [] = []
map f (x:xs) = f x : xs

sum [] = 0
sum (x:xs) = x + sum xs