Re: [BUG] APM resume breakage from 2.6.18-rc1 clocksource changes

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Thu, 13 Jul 2006, Thomas Gleixner wrote:

> > > > The timer interrupt itself is not a synchronization point.
> > > 
> > > If the timer interrupt is not a synchronization point, what is?
> 
> I used the term synchronization point for the points on the timeline,
> where the information of an external time reference is available, e.g.
> NTP data, a PPS interrupt ....

This would be even less usable, there is no requirement that NTP is used 
for time synchronization and the kernel has no idea when then the next 
NTP adjustment happens.

> At those points we calculate the deviation from the external time
> reference and refine the conversion and adjustment factors. In the
> simplest form this boils down to a linear equation where we interpolate
> between the points which are defined by the external time reference.

This is true for the clock source, but the adjustments that come in via 
NTP are not exactly linear, so unless you want to rewrite the whole NTP 
system, I don't think this will work.

> > I think this would give a bit of independence between the clocksource
> > adjustment code and the interrupt frequency (and likely improve
> > robustness as well).
> 
> John, that's exactly the central point. In an environment where we have
> non periodic interrupts (high resolution timers, dynamic ticks) this
> adjustment mechanism which relies on the periodic precise event to do
> the accumulation does not work any more. I do not like the idea of
> modifying this in a way that the timekeeping code does this fine grained
> adjustment on the non periodic timer events. This will be a nightmare of
> math and decrease robustness a lot.
> 
> The whole concept of doing the fine grained adjustment in order to
> compensate for the inaccuracy of the scaled math factors on a _periodic_
> event is flawed by design. The latency of interrupts in the kernel and
> the fact that the periodic interrupt might be driven by a different
> hardware clock, which has a different drift behaviour than the clock
> which drives the time source, are reason enough to think about a
> solution which makes this interdependency go away completely. In a high
> resolution timer / dyntick system and also on virtualized environments
> we need to get this dependency removed anyway.
> 
> The adjustment code is simply interpolation between points and boils
> down to linear equations. Due to the fact that the conversion factor is
> not accurate enough we need some mechanism to compensate this. I accept
> that the current design has its charm, but I'm quite sure that we can do
> a equally precise calculation without the interaction with the timer
> interrupt code.
> 
> I know you prefer shopping over math, but it is a solvable problem.

Thomas, do you have any idea how insulting this is?
First of all you are pretty much wrong with your analysis. It does not 
rely on "periodic precise event", it helps if they are precise, but it's 
not a requirement and it's practically a one line change so it can deal 
with nonperiodic updates (the rest is just a matter of correct tuning). 
The "fine grained adjustment" doesn't "compensate for the inaccuracy of 
the scaled math" at all, one has to know here that we only have to be 
accurate within limits (usually the resolution of the clock), so that the 
inaccuracy is not really a problem and it has the advantage that is 
generally cheap. What the adjustments actually compensate for is the 
difference in resolution and the update delays.
Since your initial analysis is pretty much wrong, your conclusions are 
pretty much useless as well. So far so bad, by itself this wouldn't be 
really a problem yet, everyone makes mistakes. If you would at least ask 
some questions about whatever problem you'd like to see solved or if you 
would make some constructive suggestion how to solve these problems, this 
would have shown respect and could have been a nice discussion. Instead 
you just piss on my work by asking John to throw away everything I did and 
to "solve" it somehow.
Did you even consider for a second that I might have already thought about 
these problems? Did it enter your mind that the hard problems might 
already be pretty much solved? Since you don't ask me at all, you don't 
really seem to care about what I think. Instead of playing Mr. 
know-it-all, I would really appreciate it if you showed some more respect 
for my work.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/