On Tuesday 08 September 2009 06:50:41 Michael Buesch wrote: > On Tuesday 08 September 2009 04:17:34 Steven Rostedt wrote: > > > Process context is too slow. > > > > Well, I'm hoping to prove the opposite. I'm working on some stuff that I > > plan to present at Linux Plumbers. I've been too distracted by other > > things, but hopefully I'll have some good numbers to present by then. > > I recently converted the b43 driver to threaded interrupt handlers and > a workqueue based TX mechanism. (My motivation was porting b43 to the SDIO bus that > needs to sleep, so requires process context). > > There are two things that I noticed. When looking at the "idle" percentage in "top" > it regressed quite a bit when using threaded IRQ handlers. It shows about 8% less > idle. This is with threaded IRQs patched in, but without WQ TX mechanism. Applying > the WQ TX mechanism does not show any noticeable effect in "top". > > I'm not quite sure where the 8% slowdown on threaded IRQ handlers come from. I'm not > really certain that it's _really_ a regression and not just a statistics accounting quirk. > Why does threaded IRQs slow down stuff and threaded TX does not at all? That does not > make sense at all to me. > > I think there's no real reason for process context being slow in general. It's just that > we have additional context switches. But these are fast on Linux. > Ok, I just did another test. I used a workqueue instead of the standard kernel threaded IRQ infrastructure. Now the slowdown is only about 4% in "top". Maybe that shows room for improvement in the threaded IRQ implementation... B43 does call mac80211's "irqsafe" TX-status and RX functions. They schedule additional tasklets. That is not required, however. Maybe I should remove that stuff and retry my tests. That should also improve stuff a bit. And yes, I notice that "top" is actually crap for testing performance issues. :) -- Greetings, Michael. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
