From: Eric Dumazet <eric.dumazet@gmail.com>
To: starlight@binnacle.cx
Cc: Joe Perches <joe@perches.com>, Christoph Lameter <cl@gentwo.org>,
Serge Belyshev <belyshev@depni.sinp.msu.ru>,
Con Kolivas <kernel@kolivas.org>,
linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>,
Willy Tarreau <w@1wt.eu>, Peter Zijlstra <a.p.zijlstra@chello.nl>,
Stephen Hemminger <stephen.hemminger@vyatta.com>
Subject: Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
Date: Wed, 05 Oct 2011 10:53:52 +0200 [thread overview]
Message-ID: <1317804832.2473.25.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> (raw)
In-Reply-To: <6.2.5.6.2.20111005025227.03a9d9f0@binnacle.cx>
Le mercredi 05 octobre 2011 à 02:58 -0400, starlight@binnacle.cx a
écrit :
> Final note:
>
> I had captured latency measurements for
> two of the three kernels. Just ran
> 2.6.18(rhel5) and the results are
> stunning. The older kernel is much,
> much better then the newer kernel.
>
> Average latency is three times better
> and the standard deviation is six
> time better. As in 300% and 600%.
>
> Latency here is the time it takes
> a packet to travel from the kernel
> (where it is timestamped) till it
> reaches the final consumption point
> in the application.
>
> Makes me think that the old kernel
> is better at keeping caches hot and
> scheduling woken threads on the same
> cores as the threads that triggered
> them.
>
Note :
Your results are from a combination of a user application and kernel
default strategies.
On other combinations, results can be completely different.
A wakeup strategy is somewhat tricky :
- Should we affine or not.
- Should we queue the wakeup on a remote CPU, to keep scheduler data hot
in a single cpu cache.
- Should we use RPS/RFS to queue the packet to another CPU before even
handling it in our stack, to keep network data hot in a single cpu
cache. (check Documentation/networking/scaling.txt)
At least, with recent kernels, we have many available choices to tune a
workload.
next prev parent reply other threads:[~2011-10-05 8:53 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-05 6:58 big picture UDP/IP performance question re 2.6.18 -> 2.6.32 starlight
2011-10-05 8:53 ` Eric Dumazet [this message]
[not found] ` <1317804832.2473.25.camel@edumazet-HP-Compaq-6005-Pr o-SFF-PC>
2011-10-05 11:50 ` starlight
-- strict thread matches above, loose matches on Subject: below --
2011-10-07 3:27 starlight
2011-10-07 5:40 ` Eric Dumazet
2011-10-07 6:13 ` starlight
2011-10-07 18:09 ` chetan loke
[not found] ` <CAAsGZS4s1wTWW1j7FRUWW9jqpPUVF3Q46AMa7+njvE1ckX0Snw @mail.gmail.com>
2011-10-07 18:37 ` starlight
2011-10-07 19:27 ` chetan loke
[not found] ` <CAAsGZS4b2F9N3nV3TNu5xG+=2d0L0ncste4xv2vqoVFb1pOxEw @mail.gmail.com>
2011-10-07 19:41 ` starlight
2011-10-07 20:07 ` Ben Hutchings
2011-10-11 16:24 ` Chris Friesen
2011-10-07 2:33 starlight
2011-10-07 2:24 starlight
2011-10-05 6:11 starlight
2011-10-05 3:35 starlight
2011-10-03 18:02 starlight
2011-10-05 6:53 ` Eric Dumazet
2011-10-03 15:25 starlight
2011-10-03 16:16 ` Eric Dumazet
[not found] ` <1317658588.2442.5.camel@edumazet-HP-Compaq-6005-Pro -SFF-PC>
2011-10-03 16:28 ` starlight
2011-10-04 19:16 ` Christoph Lameter
2011-10-04 19:38 ` Joe Perches
2011-10-04 19:42 ` Christoph Lameter
2011-10-04 19:49 ` Serge Belyshev
2011-10-04 20:03 ` Christoph Lameter
2011-10-04 20:12 ` Serge Belyshev
2011-10-04 22:32 ` Con Kolivas
2011-10-04 19:45 ` starlight
2011-10-05 13:22 ` Peter Zijlstra
2011-10-05 14:26 ` Christoph Lameter
2011-10-05 15:12 ` Andi Kleen
2011-10-05 15:33 ` Peter Zijlstra
2011-10-05 15:12 ` starlight
2011-10-02 5:33 starlight
2011-10-02 7:21 ` Eric Dumazet
2011-10-02 8:03 ` Eric Dumazet
2011-10-02 14:47 ` Stephen Hemminger
2011-10-02 15:06 ` starlight
2011-10-04 19:54 ` Loke, Chetan
2011-10-01 21:13 starlight
2011-10-01 18:16 starlight
2011-10-01 18:40 ` Willy Tarreau
2011-10-01 19:11 ` Eric Dumazet
2011-10-01 19:43 ` starlight
[not found] <6.2.5.6.2.20111001012019.05c05b80@flumedata.com>
2011-10-01 6:44 ` Eric Dumazet
2011-10-01 15:56 ` starlight
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=1317804832.2473.25.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC \
--to=eric.dumazet@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=belyshev@depni.sinp.msu.ru \
--cc=cl@gentwo.org \
--cc=joe@perches.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=starlight@binnacle.cx \
--cc=stephen.hemminger@vyatta.com \
--cc=w@1wt.eu \
/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