lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 8 Sep 2009 07:08:58 +0200 From: Michael Buesch <mb@...sch.de> To: rostedt@...dmis.org Cc: Stephen Hemminger <shemminger@...tta.com>, "Luis R. Rodriguez" <mcgrof@...il.com>, Ingo Molnar <mingo@...e.hu>, "John W. Linville" <linville@...driver.com>, linux-wireless <linux-wireless@...r.kernel.org>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Matt Smith <Matt.Smith@...eros.com>, Kevin Hayes <kevin@...eros.com>, Bob Copeland <me@...copeland.com>, Jouni Malinen <j@...fi>, Ivan Seskar <Seskar@...lab.rutgers.edu>, ic.felix@...il.com Subject: Re: Stop using tasklets for bottom halves 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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists