From owner-freebsd-net@FreeBSD.ORG  Fri Oct 14 17:47:20 2005
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1491916A41F
	for <net@freebsd.org>; Fri, 14 Oct 2005 17:47:20 +0000 (GMT)
	(envelope-from mreimer@vpop.net)
Received: from ring.vpop.net (ring.vpop.net [207.178.248.5])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CB0C843D4C
	for <net@freebsd.org>; Fri, 14 Oct 2005 17:47:19 +0000 (GMT)
	(envelope-from mreimer@vpop.net)
Received: from bilbo.vpop.net (bilbo.vpop.net [70.56.77.194])
	by ring.vpop.net (Postfix) with ESMTP id 2648EAFAA78
	for <net@freebsd.org>; Fri, 14 Oct 2005 10:47:14 -0700 (PDT)
From: Matthew Reimer <mreimer@vpop.net>
Organization: VPOP Technologies, Inc.
To: net@freebsd.org
Date: Fri, 14 Oct 2005 10:46:11 -0700
User-Agent: KMail/1.8.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510141046.11620.mreimer@vpop.net>
Cc: 
Subject: Re: Call for performance evaluation: net.isr.direct (fwd)
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Oct 2005 17:47:20 -0000

Poul-Henning Kamp wrote:

> In message <17231.50841.442047.622878@grasshopper.cs.duke.edu>, Andrew
> Gallatin
>  writes:
> 
>> > >What if somebody were to port the linux TSC syncing code, and use it
>> > >to decide whether or not set kern.timecounter.smp_tsc=1?  Would you
>> > >object to that?
>> > 
>> > Yes, I would object to that.
>> > 
>> > Even to this day new CPU chips come out where TSC has flaws that
>> > prevent it from being used as timecounter, and we do not have (NDA)
>> > access to the data that would allow us to build a list of safe
>> > hardware.
>>
>>Bear in mind that I have no clue about timekeeping.  I got into this
>>just because I noticed using a TSC timecounter reduces context switch
>>latency by 40% or more on all the SMP platforms I have access to:
>>
>>1.0GHz dual PIII : 50% reduction vs i8254
>>3.06GHz 1 HTT P4 : 55% vs ACPI-safe, 70% vs i8254)
>>2.0GHz dual amd64: 43% vs ACPI-fast, 60% vs i8254)
> 
> The solution is not faster but less reliable timekeeping, the
> solution is to move the scheduler(s) away from using time as an
> approximation of cpu cycles.

Would the hardware performance counters be suitable for that, at least on 
processors that have them?

Matt