netdev - 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: <200909080650.43181.mb@bu3sch.de>
Date:	Tue, 8 Sep 2009 06:50:41 +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 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.

-- 
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