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]
Date:	Mon, 4 Jun 2007 21:47:59 +0200
From:	Maximilian Engelhardt <>
To:	Ingo Molnar <>
Cc:	Stephen Hemminger <>,
	Thomas Gleixner <>,
	Ulrich Drepper <>,
	Michael Buesch <>,
	linux-kernel <>,
	linux-wireless <>,
	Arnaldo Carvalho de Melo <>,
	Jeff Garzik <>,
	Gary Zambrano <>,,
	Andrew Morton <>
Subject: Re: iperf: performance regression (was b44 driver problem?)

On Monday 04 June 2007, Ingo Molnar wrote:
> * Stephen Hemminger <> wrote:
> > Yes, the following patch makes iperf work better than ever. But are
> > other broken applications going to have same problem. Sounds like the
> > old "who runs first" fork() problems.
> this is the first such app and really, and even for this app: i've been
> frequently running iperf on -rt kernels for _years_ and never noticed
> how buggy its 'locking' code was, and that it would under some
> circumstances use up the whole CPU on high-res timers.

I must admit I don't know much about that topic, but there is one thing I 
don't understand. Why is iperf (even if it's buggy) able to use up the whole 
cpu? I didn't run it as root but as my normal user so it should have limited 
rights. Shouldn't the linux scheduler distribute cpu time among all running 


Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists