> I've come to the conclusion that Eric is right> and the primary issue is an increase in the> cost of scheduler context switches. Have> been watching this number and it has held> pretty close to 200k/sec under all scenarios> and kernel versions, so it has to be> a longer code-path, bigger cache pressure> or both in the scheduler. Sadly this makes> newer kernels a no-go for us.

We had similar experiences. Basically latency constantly gets screwed upby the new fancy features being added to the scheduler and networksubsystem (most notorious is the new "fair" scheduler, 2.6.23 made a bigstep down). The kernel has a fairly constant regression in terms oflatency release after release. Only the new and more efficient processorsperiodically provide some compensation (and some isolated patches toactually improve things get in but these are usually watered down one ortwo releases after those improvements have been made).Linux version 2.6.39.4 (x@x) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Sat Oct 1 21:11:47 EDT 2011