On Monday 04 June 2007, Ingo Molnar wrote: > * Stephen Hemminger <[email protected]> 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
- Follow-Ups:
- Re: iperf: performance regression (was b44 driver problem?)
- From: Stephen Hemminger <[email protected]>
- Re: iperf: performance regression (was b44 driver problem?)
- References:
- Re: iperf: performance regression (was b44 driver problem?)
- From: Stephen Hemminger <[email protected]>
- Re: iperf: performance regression (was b44 driver problem?)
- From: Ingo Molnar <[email protected]>
- Re: iperf: performance regression (was b44 driver problem?)
- Prev by Date: Re: [PATCH] Performance Stats: Kernel patch
- Next by Date: Re: [RFC 1/7] cpuset write dirty map
- Previous by thread: Re: iperf: performance regression (was b44 driver problem?)
- Next by thread: Re: iperf: performance regression (was b44 driver problem?)
- Index(es):
 |