Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

[Andi Kleen <ak@suse.de>]

"Vladimir B. Savkin" <master@sectorb.msk.ru> writes:

[you seem to send your emails in a strange way that doesn't keep me in cc.
Please stop doing that.]

> On Mon, Sep 18, 2006 at 11:58:21AM +0200, Andi Kleen wrote:
> > > > The x86-64 timer subsystems currently doesn't have clocksources
> > > > at all, but it supports TSC and some other timers.
> > > 
> > 
> > > until I hacked arch/i386/kernel/tsc.c
> > 
> > Then you don't use x86-64. 
> > 
> Oh. I mean I made arch/i386/kernel/tsc.c compile on x86-64
> by hacking some Makefiles and headers. 

The codebase for timing (and lots of other things) is quite different
between 32bit and 64bit. You're really surprised it doesn't work if you do such things?

> But the question is, why stock 2.6.18-rc7 could not use TSC on its own?

x86-64 doesn't use the TSC when it deems it to not be reliable, which
is the case on your system.
 
> > > > > I've also had experience of unsychronized TSC on dual-core Athlon,
> > > > > but it was cured by idle=poll.
> > > > 
> > > > You can use that, but it will make your system run quite hot 
> > > > and cost you a lot of powe^wmoney.
> > > 
> > > Here in Russia electric power is cheap compared with hardware upgrade.
> > 
> > It's not just electrical power - the hardware is more stressed and will
> > likely fail earlier too.  As a rule of thumb the hotter your hardware runs
> > the earlier it will fail.
> 
> What hardware exactly. Doesn't it affect only CPU? And they are not
> know to fail before any other components.

All hardware. It's basic physics.

-Andi