From: Andi Kleen <ak@suse.de>
To: Thomas Graf <tgraf@suug.ch>
Subject: Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
Date: Tue, 19 Sep 2006 22:43:27 +0200
User-Agent: KMail/1.9.3
Cc: David Miller <davem@davemloft.net>, kuznet@ms2.inr.ac.ru,
       master@sectorb.msk.ru, hawk@diku.dk, harry@atmos.washington.edu,
       linux-kernel@vger.kernel.org, netdev@vger.kernel.org
References: <20060918162847.GA4863@ms2.inr.ac.ru> <20060918.142247.14844785.davem@davemloft.net> <20060919203105.GF18349@postel.suug.ch>
In-Reply-To: <20060919203105.GF18349@postel.suug.ch>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200609192243.27511.ak@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 976
Lines: 23


> It seems only natural to me that the real problem is the slow
> clock source which needs to be resolved regardless of the
> outcome of this discussion. I believe that updating the stamp
> at socket enqueue time is the right thing to do but it shouldn't
> be considered as a solution to the performance problem.

While I agree it would be nice to fix that particular issue 
(it's unfortunately hard) slow clock sources in general won't go
away. They are also in lots of other platforms.

And even if you have a fast clock source not using it when you
don't need to is better. For example some x86s can be quite
slow even reading TSCs. It's much better than pmtmr
it's still is a expensive operations that is best avoided.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/