From: Andi Kleen <andi@firstfloor.org>
To: Christoph Lameter <cl@gentwo.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	starlight@binnacle.cx, Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	Willy Tarreau <w@1wt.eu>, Ingo Molnar <mingo@elte.hu>
Subject: Re: big picture UDP/IP performance question re 2.6.18  -> 2.6.32
Date: Wed, 05 Oct 2011 08:12:44 -0700	[thread overview]
Message-ID: <m2mxdf4glv.fsf@firstfloor.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1110050915160.30467@router.home> (Christoph Lameter's message of "Wed, 5 Oct 2011 09:26:24 -0500 (CDT)")
Christoph Lameter <cl@gentwo.org> writes:
> On Wed, 5 Oct 2011, Peter Zijlstra wrote:
>
>> Clearly none of the tests being ran on a regular basis, by for instance
>> the Intel regression team, covers your needs. Start by fixing that.
>
> The most commonly run, the aged old tests contained in the AIM9 suite,
> have consistently shown these regressions over long years and they have
> been brought up repeatedly in numerous discussions. This is pervasive
> thoughout the OS hotpaths. Just look at how the page fault latencies
> change over time. Take a modern machine and then run successively older
> kernel versions on it. You will see performance getting better and
> latencies becoming smaller.
One of the reason the Intel tests fix problems is that Alex and Tim
and others look into them and track down regressions. If you see
a new problem during your testing you should do the same.
This actually helps.
It doesn't need to be a full analysis/patch, even just posting some detailed
information on a new regression is useful.
For example one tool I found useful is to just enable the function
graph tracer and look at the latencies of functions in that path
during the test. 
If something changes dramatically it's relatively easy to point to.
So for example if you see context switch changing it should not 
be that difficult to do such a trace and at least point to the guilty
functions and post a mail.
>> Also, for latency, we've got ftrace and a latencytracer, provide traces
>> that illustrate your fail.
>
> We would need a backport of both to a kernel version that works with
> reasonable latencies so that we can figure out what caused these
> regressions for this particular case. Disabling network and kernel
> features usually gives you better performance but there are a lot of
> things in the hot paths these days that can not be disabled.
Please do function traces and point fingers at slow things in hotpath.
The more the merrier. Post a list of a shame!
-Andi
-- 
ak@linux.intel.com -- Speaking for myself only
next prev parent reply	other threads:[~2011-10-05 15:12 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 15:25 big picture UDP/IP performance question re 2.6.18 -> 2.6.32 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 [this message]
2011-10-05 15:33       ` Peter Zijlstra
2011-10-05 15:12     ` 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:58 starlight
2011-10-05  8:53 ` Eric Dumazet
     [not found]   ` <1317804832.2473.25.camel@edumazet-HP-Compaq-6005-Pr o-SFF-PC>
2011-10-05 11:50     ` 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-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=m2mxdf4glv.fsf@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cl@gentwo.org \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=starlight@binnacle.cx \
    --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;
as well as URLs for NNTP newsgroup(s).