Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32

Christoph Lameter [off-list ref] writes:

On Wed, 5 Oct 2011, Peter Zijlstra wrote:

quoted

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.

quoted

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