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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ