[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200706042148.02450.maxi@daemonizer.de>
Date: Mon, 4 Jun 2007 21:47:59 +0200
From: Maximilian Engelhardt <maxi@...monizer.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ulrich Drepper <drepper@...il.com>,
Michael Buesch <mb@...sch.de>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Jeff Garzik <jgarzik@...ox.com>,
Gary Zambrano <zambrano@...adcom.com>, netdev@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: iperf: performance regression (was b44 driver problem?)
On Monday 04 June 2007, Ingo Molnar wrote:
> * Stephen Hemminger <shemminger@...ux-foundation.org> 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
processes?
Maxi
Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists