From: Thomas Gleixner <tglx@linutronix.de>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Ulrich Drepper <drepper@gmail.com>,
Maximilian Engelhardt <maxi@daemonizer.de>,
Michael Buesch <mb@bu3sch.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Jeff Garzik <jgarzik@pobox.com>,
Gary Zambrano <zambrano@broadcom.com>,
netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: iperf: performance regression (was b44 driver problem?)
Date: Mon, 04 Jun 2007 21:26:18 +0200 [thread overview]
Message-ID: <1180985178.4404.48.camel@chaos> (raw)
In-Reply-To: <1180983647.4404.38.camel@chaos>
On Mon, 2007-06-04 at 21:00 +0200, Thomas Gleixner 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.
>
> Not really. The fork() "who runs first" problem is nowhere specified.
>
> usleep(0) is well defined:
>
> .... If the value of useconds is 0, then the call has no effect.
>
> So the call into the kernel has been wrong for quite a time.
>
Just for clarification: I'm not saying that we should break the (broken)
user space ABI. I'm going to work out a patch which prints out a warning
(limited number per boot) and emulating the old behavior by a call to
yield() along with an entry into (mis)feature-removal.txt.
tglx
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
To: Stephen Hemminger
<shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Ulrich Drepper <drepper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Maximilian Engelhardt
<maxi-OwNUvPV92VfddJNmlsFzeA@public.gmane.org>,
Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>,
linux-kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-wireless
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Arnaldo Carvalho de Melo
<acme-f8uhVLnGfZaxAyOMLChx1axOck334EZe@public.gmane.org>,
Jeff Garzik <jgarzik-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>,
Gary Zambrano <zambrano-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Subject: Re: iperf: performance regression (was b44 driver problem?)
Date: Mon, 04 Jun 2007 21:26:18 +0200 [thread overview]
Message-ID: <1180985178.4404.48.camel@chaos> (raw)
In-Reply-To: <1180983647.4404.38.camel@chaos>
On Mon, 2007-06-04 at 21:00 +0200, Thomas Gleixner 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.
>
> Not really. The fork() "who runs first" problem is nowhere specified.
>
> usleep(0) is well defined:
>
> .... If the value of useconds is 0, then the call has no effect.
>
> So the call into the kernel has been wrong for quite a time.
>
Just for clarification: I'm not saying that we should break the (broken)
user space ABI. I'm going to work out a patch which prints out a warning
(limited number per boot) and emulating the old behavior by a call to
yield() along with an entry into (mis)feature-removal.txt.
tglx
next prev parent reply other threads:[~2007-06-04 19:26 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-26 0:24 b44: regression in 2.6.22 Stephen Hemminger
2007-05-26 3:51 ` Gary Zambrano
2007-05-26 17:01 ` Michael Buesch
2007-05-27 19:25 ` b44: regression in 2.6.22 (resend) Maximilian Engelhardt
2007-05-27 19:25 ` Maximilian Engelhardt
2007-05-27 19:45 ` Michael Buesch
2007-05-27 19:45 ` Michael Buesch
2007-05-27 20:36 ` Maximilian Engelhardt
2007-05-27 20:36 ` Maximilian Engelhardt
2007-05-27 20:46 ` Michael Buesch
2007-05-27 20:46 ` Michael Buesch
2007-05-27 21:46 ` Maximilian Engelhardt
2007-05-27 21:46 ` Maximilian Engelhardt
2007-05-27 21:13 ` Michael Buesch
2007-05-27 21:13 ` Michael Buesch
2007-05-27 21:16 ` Michael Buesch
2007-05-27 21:50 ` Maximilian Engelhardt
2007-05-27 21:50 ` Maximilian Engelhardt
2007-05-27 22:15 ` Maximilian Engelhardt
2007-05-27 22:15 ` Maximilian Engelhardt
2007-05-28 0:24 ` Michael Buesch
2007-05-28 0:40 ` Maximilian Engelhardt
2007-05-28 0:40 ` Maximilian Engelhardt
2007-05-28 10:16 ` Michael Buesch
2007-05-28 10:16 ` Michael Buesch
2007-05-28 14:09 ` Maximilian Engelhardt
2007-05-28 14:09 ` Maximilian Engelhardt
2007-05-28 15:14 ` Michael Buesch
2007-05-28 15:14 ` Michael Buesch
2007-05-28 15:32 ` Thomas Gleixner
2007-05-28 15:32 ` Thomas Gleixner
2007-05-28 15:43 ` Michael Buesch
2007-05-28 15:43 ` Michael Buesch
2007-05-28 17:44 ` Maximilian Engelhardt
2007-05-28 19:23 ` Thomas Gleixner
2007-05-28 20:55 ` Maximilian Engelhardt
2007-05-28 21:45 ` Thomas Gleixner
2007-05-29 18:28 ` Maximilian Engelhardt
2007-05-29 18:28 ` Maximilian Engelhardt
2007-05-29 13:58 ` Gary Zambrano
2007-05-29 13:58 ` Gary Zambrano
2007-05-29 17:23 ` Maximilian Engelhardt
2007-05-29 17:23 ` Maximilian Engelhardt
2007-06-03 16:26 ` Maximilian Engelhardt
2007-06-04 6:39 ` Thomas Gleixner
2007-06-04 6:39 ` Thomas Gleixner
2007-06-04 16:09 ` Stephen Hemminger
2007-06-04 16:09 ` Stephen Hemminger
2007-06-04 16:35 ` Thomas Gleixner
2007-06-04 16:35 ` Thomas Gleixner
2007-06-04 16:59 ` iperf: performance regression (was b44 driver problem?) Stephen Hemminger
2007-06-04 17:32 ` Thomas Gleixner
2007-06-04 17:32 ` Thomas Gleixner
2007-06-04 17:51 ` Stephen Hemminger
2007-06-04 19:00 ` Thomas Gleixner
2007-06-04 19:26 ` Thomas Gleixner [this message]
2007-06-04 19:26 ` Thomas Gleixner
2007-06-04 19:32 ` Ingo Molnar
2007-06-04 19:47 ` Maximilian Engelhardt
2007-06-04 20:02 ` Stephen Hemminger
2007-06-04 20:52 ` Maximilian Engelhardt
2007-06-04 20:52 ` Maximilian Engelhardt
2007-05-28 10:49 ` b44: regression in 2.6.22 (resend) Michael Buesch
2007-05-28 14:12 ` Maximilian Engelhardt
2007-05-28 14:12 ` Maximilian Engelhardt
2007-05-28 14:55 ` Michael Buesch
2007-05-29 14:14 ` Gary Zambrano
2007-05-29 20:45 ` Michael Buesch
2007-05-29 20:45 ` Michael Buesch
2007-05-29 21:01 ` Stephen Hemminger
2007-05-29 21:01 ` Stephen Hemminger
2007-05-29 21:05 ` Gary Zambrano
2007-05-29 21:05 ` Gary Zambrano
2007-05-29 22:39 ` Jeff Garzik
2007-05-29 22:39 ` Jeff Garzik
2007-05-29 21:36 ` Gary Zambrano
2007-05-29 21:36 ` Gary Zambrano
2007-05-30 10:45 ` Michael Buesch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1180985178.4404.48.camel@chaos \
--to=tglx@linutronix.de \
--cc=acme@ghostprotocols.net \
--cc=akpm@linux-foundation.org \
--cc=drepper@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=maxi@daemonizer.de \
--cc=mb@bu3sch.de \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=zambrano@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.