On Tue, 2003-01-21 at 15:27, Andi Kleen wrote:
> Comments:
>
> Basic idea is good. The x86-64 2.4 tree has a similar solution for the
> same problem. Especially with HZ=1000 this is really needed, because
> now lost ticks are far more common than with the HZ=100 in 2.4.
> I would consider some form of this patch as requirement for 2.6 release.
>
> what happens when 1000000 does not evenly divide HZ?
> I think some ports use HZ=1024
Then it comes out to close enough? I'm probably just not getting the
problem. Could you further explain?
> Why is the condition > and not >= ? Eactly two ticks offset is already
> one lost. In fact even >= 1.5*HZ would be dubious.
Exactly two, yes. However 1.5 wouldn't quite do it, as jiffies would be
incremented once and delay_at_last_interrupt should be set to .5*HZ,
thus loosing no time.
> I would like to have some statistics counter somewhere in /proc for lost
> ticks, so that it can be checked for after bug reports. Perhaps even
> printk for the first 5 or so.
Yea, I had some printk code in there, but I have a card here that can
cause 30ms SMI stalls once per sec, so it was getting a bit verbose.
Although printing out for the first five, would be fine. I'll add that
right away. Thanks!
> Could you please add spaces after /* and before */
Doh, I read and read those style guidelines, but my fingers never seem
to take to em'.
thanks again,
-john
-
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/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:28 EST