Messages in this thread | | | Date | Mon, 15 Mar 1999 12:55:08 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] recover losed timer interrupt using the TSC [Re: [patch] kstat change to see how much Linux SMP really scale well] |
| |
On Mon, 15 Mar 1999, Ingo Molnar wrote:
>this is not necessarily robust. Timekeeping so far was pretty much >independent of the cycle counter. (micro-time is not, but generic >timekeeping yes). Now with your patch if the cycle counter produces >something funny, we'd not only get a message, but also broken time.
If the tsc goes as hell gettimeofday will die too, and the TSC is explicity declared from Intel as a really safely trustable thing, so if the TSC will die I expect many other part of the CPU to die too.
>i think Andrea you are losing the generic picture. 10 msecs is _alot_ of >time, especially on systems that have a time stamp counter. We should
And maybe somebody may really intentionally take the cpu clied for more than 10msec for some strange usage.
>_not_ block interrupts for more than 10 msecs. If we do then yes we've >lost a few ticks (we've lost them in previous Linux versions too, so >this is certainly nothing new), but now we also got a message so people >can fix it. You've just increased complexity in an already complex and >hard to
Since we'll printk a message anyway and so we have just increased the complexity of the code anyway, so why not to also recover the lost tick in a slow path as I do?
>maintain piece of code to 'fix' the symptom of a fundamentally broken and >rare case, instead of just detecting and fixing the real reason.
I am not fixing the symptom, I am recovering the bug at runtime kprinting the useful information as in your patch but with the difference that then I am allowing the machine to run fine until the problem will get fixed (and to get it fixed you may need to wait some time like in the scsi code).
Andrea Arcangeli
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |