linux-kernel - Re: Stop using tasklets for bottom halves

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200909080708.59702.mb@bu3sch.de>
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/