Please pull from lost-spurious-irq
in [Kernel]
|
Prev: hpwdt: make NMI code a config option (+ other cleanup)
Next: linux-next: manual merge of the staging-next tree with the v4l-dvb tree
From: Thomas Gleixner on 2 Aug 2010 18:00 Tejun, On Mon, 2 Aug 2010, Tejun Heo wrote: > Hello, Thomas. > > On 08/02/2010 08:52 PM, Thomas Gleixner wrote: > >> Ooh, another reason is timer locality. If timers are shared per desc, > >> they have much higher chance of being on the same processor. Global > >> timers would be pretty bad in that respect. > > > > That's irrelevant. If you need to poll an interrupt, then it does not > > matter at all whether you bounce some cache lines or not. > > > > In fact we have two cases: > > > > 1) An interrupt needs to be polled all the time. That sucks whether > > the poll timer bounces a few cache lines or not. > > > > 2) Polling an irq for some time. Either it works again after a > > while, so your suckage is restricted to the poll period. If not > > see #1 > > Hmm... for spurious and watch the above are true and if it were the > above two it would definitely make more sense to use per-purpose > global timers. The problem is w/ expect tho. It's supposed to be > used with normal hot paths, so expect/unexpect operations better be > low overhead and local. I'll talk more about it in the other reply. No, it's not. You are just looking at it from the wrong perspective. The expect scenario is just a different form of watch. You worked around the problem by moving the timer to 3 seconds + slack if everything works as expected, but that's just sloppy. In fact you really want to kick that thing in when things go awry and take it away when it comes back to normal. When things go awry, then the cache line bouncing is the least of your worries, really. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 3 Aug 2010 06:10 On Mon, 2 Aug 2010, Tejun Heo wrote: > > And it's even less of an issue as the main users of this misfeature > > are laptops and desktop machines, where locality is not really that > > important. If an enterprise admin decides to ignore the fact that the > > hardware is flaky, then he does not care about the cache line bounces > > either. > > These problems do happen on intel chipset machines and is something > which can be worked around with some effort. Eh, let's talk on the > other reply. So you're saying that the ATA problem is restricted to Intel chipsets? Do we know the root cause ? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 3 Aug 2010 06:30 Hello, On 08/03/2010 12:06 PM, Thomas Gleixner wrote: >> These problems do happen on intel chipset machines and is something >> which can be worked around with some effort. Eh, let's talk on the >> other reply. > > So you're saying that the ATA problem is restricted to Intel chipsets? > Do we know the root cause ? The original sentence is missing an 'also'. Severals have been root caused and worked around. For SATA, one of the notable problems was misinterpretation of nIEN (interrupt block bit on the ATA device side) on both device and host sides. In traditional IDE API, the interrupt bit is primarily under the control of the device, so it's pretty difficult to guarantee reliable operation from driver side only. For PATA, the device actually has full control of the interrupt line, so it's much worse. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 3 Aug 2010 07:50
Tejun, On Tue, 3 Aug 2010, Tejun Heo wrote: > I agree that timer multiplexing is a rather ugly thing and it would be > great to remove it. You're right that it doesn't make whole lot of > difference whether the timer is global or local if it's low frequency > and in fast paths expect/unexpect would be able to just test its list > entry and set/clear currently expecting status without messing with > the global timer or lock. Then, we can have a single low freq timer > for expect/unexpect and the other for actual polling. And the third one for watch, right ? That would give us separate timer functions which each serve a particular purpose. When you go for it, can you please simplify all the heuristics? spurious poll: One fixed poll interval is enough. The retry logic can be made simple, just set it back to interrupt delivery once per minute and limit the storm to 10. watch: Get rid of the interrupt context work and do all the work in the timer. Use a fixed interval and either keep it forever or remove it. expect: Use a slow fixed interval and just do the expect/unexpect fast marking. A nice thing would be to have a counter of expect calls so we can switch off the timer when there is no activity within 10 seconds. > How does that sound to you? Way better. :) Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |