![]() | |||||||||||||
Messages in this thread |
On Fri, May 13, 2005 at 06:56:33PM -0400, Lee Revell wrote: > On Sat, 2005-05-14 at 00:51 +0200, Pavel Machek wrote: > > Hi! > > > > > > > > Because it kills machine when interrupt latency gets too high? > > > > > > Like reading battery status using i2c... > > > > > > > > > > That's a bug in the I2C reader then. Don't shot the messenger for bad news. > > > > > > > > Disagreed. > > > > > > > > Linux is not real time OS. Perhaps some real-time constraints "may not > > > > spend > 100msec with interrupts disabled" would be healthy > > > ^^^^ > > > You mean "microseconds", right? 100ms will be perceived by the user as, > > > well, their machine freezing for 100ms... > > > > I did mean miliseconds. IIRC current watchdog is at one second and it > > still triggers even in cases when operation just takes too long. > > I thought there was an understanding that 1 ms would be the target for > desktop responsiveness. So yes, disabling interrupts for more than 1ms > is considered a bug. No, it's a bit different. Let's say disabling interrupts after boot even for considerable fractions of 1ms is a bug. But then there are exceptional circumstances where you have no other choice. In that case you need to use touch_nmi_watchdog yourself. But these things should be rare, e.g. only in unlikely error handling situations. > > Why do you need to disable interrupts for 100ms to read the battery > status exactly? I guess because he's too lazy to rewrite the code use semaphores and schedule_timeout(). He just needs to get over that. -Andi - 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/ | ||||||||||||
| Last update: 2005-05-15 12:57 [from the cache] ©2003-2008 | |||||||||||||