From: Eric Dumazet <dada1@cosmosbay.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: Evgeniy Polyakov <zbr@ioremap.net>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Ingo Molnar <mingo@elte.hu>,
Evgeniy Polyakov <s0mbre@tservice.net.ru>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David Miller <davem@davemloft.net>,
Mike Galbraith <efault@gmx.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.
Date: Thu, 30 Oct 2008 19:56:36 +0100 [thread overview]
Message-ID: <490A0364.3040902@cosmosbay.com> (raw)
In-Reply-To: <490A0054.2030903@cosmosbay.com>
Eric Dumazet a écrit :
> Stephen Hemminger a écrit :
>> Has anyone looked into the impact of port randomization on this
>> benchmark.
>> If it is generating lots of sockets quickly there could be an impact:
>> * port randomization causes available port space to get filled
>> non-uniformly
>> and what was once a linear scan may have to walk over existing ports.
>> (This could be improved by a hint bitmap)
>>
>> * port randomization adds at least one modulus operation per socket
>> creation. This could be optimized by using a loop instead.
>
>
>
> tbench setups one socket per client, then send/receive lot of messages
> on this socket.
>
> Connection setup time can be ignored for the tbench regression analysis
>
Hum, re-reading your question, I feel you might have a valid point after all :)
Not because of connection setup time, but because the rwlocks used on tcp hash table.
tcp sessions used on this tbench test might now be on the same cache lines,
because of port randomization or so.
CPUS might do cache-line ping pongs on those rwlocks.
# netstat -tn|grep 7003
tcp 0 59 127.0.0.1:37248 127.0.0.1:7003 ESTABLISHED
tcp 0 71 127.0.0.1:7003 127.0.0.1:37252 ESTABLISHED
tcp 0 0 127.0.0.1:37251 127.0.0.1:7003 ESTABLISHED
tcp 0 4155 127.0.0.1:7003 127.0.0.1:37249 ESTABLISHED
tcp 0 55 127.0.0.1:7003 127.0.0.1:37248 ESTABLISHED
tcp 0 0 127.0.0.1:37252 127.0.0.1:7003 ESTABLISHED
tcp 0 0 127.0.0.1:37249 127.0.0.1:7003 ESTABLISHED
tcp 0 59 127.0.0.1:37246 127.0.0.1:7003 ESTABLISHED
tcp 0 0 127.0.0.1:37250 127.0.0.1:7003 ESTABLISHED
tcp 71 0 127.0.0.1:37245 127.0.0.1:7003 ESTABLISHED
tcp 0 0 127.0.0.1:37244 127.0.0.1:7003 ESTABLISHED
tcp 0 87 127.0.0.1:7003 127.0.0.1:37250 ESTABLISHED
tcp 0 4155 127.0.0.1:7003 127.0.0.1:37251 ESTABLISHED
tcp 0 4155 127.0.0.1:7003 127.0.0.1:37246 ESTABLISHED
tcp 0 71 127.0.0.1:7003 127.0.0.1:37245 ESTABLISHED
tcp 0 4155 127.0.0.1:7003 127.0.0.1:37244 ESTABLISHED
We use a jhash, so normally we could expect a really random split of hash values
for all these sessions, but it would be worth to check :)
You know understand why we want to avoid those rwlocks Stephen, and switch to RCU...
next prev parent reply other threads:[~2008-10-30 18:57 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 23:17 [tbench regression fixes]: digging out smelly deadmen Evgeniy Polyakov
2008-10-10 5:40 ` Peter Zijlstra
2008-10-10 8:09 ` Evgeniy Polyakov
2008-10-10 9:15 ` Ingo Molnar
2008-10-10 11:31 ` Evgeniy Polyakov
2008-10-10 11:40 ` Ingo Molnar
2008-10-10 13:25 ` Evgeniy Polyakov
2008-10-10 11:42 ` Ingo Molnar
2008-10-10 11:55 ` Evgeniy Polyakov
2008-10-10 11:57 ` Ingo Molnar
2008-10-24 22:25 ` Rafael J. Wysocki
2008-10-24 23:31 ` David Miller
2008-10-25 4:05 ` Mike Galbraith
2008-10-25 5:15 ` David Miller
2008-10-25 5:53 ` Mike Galbraith
2008-10-25 11:13 ` Rafael J. Wysocki
2008-10-26 3:55 ` David Miller
2008-10-26 11:33 ` Rafael J. Wysocki
2008-10-25 3:37 ` Mike Galbraith
2008-10-25 5:16 ` David Miller
2008-10-25 5:58 ` Mike Galbraith
2008-10-25 6:53 ` Mike Galbraith
2008-10-25 7:24 ` David Miller
2008-10-25 7:52 ` Mike Galbraith
2008-10-25 23:10 ` Jiri Kosina
2008-10-26 8:46 ` Mike Galbraith
2008-10-26 9:00 ` Peter Zijlstra
2008-10-26 9:11 ` Andrew Morton
2008-10-26 9:27 ` Evgeniy Polyakov
2008-10-26 9:34 ` Andrew Morton
2008-10-26 10:05 ` Evgeniy Polyakov
2008-10-27 2:34 ` David Miller
2008-10-27 9:30 ` Ingo Molnar
2008-10-27 9:57 ` David Miller
2008-10-26 10:23 ` Mike Galbraith
2008-10-26 19:03 ` Jiri Kosina
2008-10-27 9:29 ` Mike Galbraith
2008-10-27 10:42 ` Jiri Kosina
2008-10-27 11:27 ` Ingo Molnar
2008-10-27 11:33 ` Alan Cox
2008-10-27 12:06 ` Mike Galbraith
2008-10-27 13:42 ` Jiri Kosina
2008-10-27 14:17 ` Mike Galbraith
2008-10-27 18:33 ` Ingo Molnar
2008-10-27 19:39 ` Evgeniy Polyakov
2008-10-27 19:48 ` David Miller
2008-10-28 10:24 ` Mike Galbraith
2008-10-28 10:37 ` Ingo Molnar
2008-10-28 10:57 ` Mike Galbraith
2008-10-28 11:02 ` Ingo Molnar
2008-10-28 14:00 ` Mike Galbraith
2008-10-28 15:22 ` Mike Galbraith
2008-10-29 9:14 ` Evgeniy Polyakov
2008-10-29 9:50 ` Evgeniy Polyakov
2008-11-01 12:51 ` Paolo Ciarrocchi
2008-10-29 9:59 ` Nick Piggin
2008-10-26 9:15 ` Mike Galbraith
2008-10-25 7:19 ` David Miller
2008-10-25 7:33 ` Mike Galbraith
2008-10-27 17:26 ` Rick Jones
2008-10-27 19:11 ` Mike Galbraith
2008-10-27 19:18 ` Rick Jones
2008-10-27 19:44 ` Mike Galbraith
2008-10-26 11:29 ` Evgeniy Polyakov
2008-10-26 12:23 ` Evgeniy Polyakov
2008-10-30 18:15 ` Stephen Hemminger
2008-10-30 18:40 ` Evgeniy Polyakov
2008-10-30 18:43 ` Eric Dumazet
2008-10-30 18:56 ` Eric Dumazet [this message]
2008-10-30 19:01 ` Ilpo Järvinen
2008-10-31 7:52 ` David Miller
2008-10-31 9:40 ` Ilpo Järvinen
2008-10-31 9:51 ` David Miller
2008-10-31 10:42 ` Ilpo Järvinen
2008-10-31 10:45 ` Eric Dumazet
2008-10-31 11:01 ` Ilpo Järvinen
2008-10-31 11:10 ` Eric Dumazet
2008-10-31 11:15 ` Ilpo Järvinen
2008-10-31 19:57 ` Stephen Hemminger
2008-10-31 20:10 ` Evgeniy Polyakov
2008-10-31 21:03 ` Eric Dumazet
2008-10-31 21:18 ` Evgeniy Polyakov
2008-10-31 23:51 ` David Miller
2008-10-31 23:56 ` Stephen Hemminger
2008-11-01 0:16 ` Jay Vosburgh
2008-11-02 4:40 ` David Miller
2008-11-04 2:13 ` [PATCH net-next-2.6] bonding, net: Move last_rx update into bonding recv logic Jay Vosburgh
2008-11-04 2:17 ` David Miller
2008-10-10 10:13 ` [tbench regression fixes]: digging out smelly deadmen Mike Galbraith
2008-10-11 13:13 ` Evgeniy Polyakov
2008-10-11 14:39 ` Peter Zijlstra
2008-10-11 18:13 ` Mike Galbraith
2008-10-12 6:02 ` Mike Galbraith
2008-10-12 6:33 ` Mike Galbraith
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=490A0364.3040902@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=s0mbre@tservice.net.ru \
--cc=shemminger@vyatta.com \
--cc=zbr@ioremap.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).