From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 12:52:31 2005 Return-Path: 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 373D416A420 for ; Fri, 14 Oct 2005 12:52:31 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01BB43D5C for ; Fri, 14 Oct 2005 12:52:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id j9ECqRir025257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 08:52:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id j9ECqLGe013276; Fri, 14 Oct 2005 08:52:21 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.43525.446450.161986@grasshopper.cs.duke.edu> Date: Fri, 14 Oct 2005 08:52:21 -0400 (EDT) To: "Poul-Henning Kamp" In-Reply-To: <12907.1129286370@critter.freebsd.dk> References: <20051014192509.F80520@delplex.bde.org> <12907.1129286370@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Garrett Wollman , net@FreeBSD.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 12:52:31 -0000 Poul-Henning Kamp writes: > The best compromise solution therefore is to change the scheduler > to make decisions based on the TSC ticks (or equivalent on other > archs) and at regular intervals figure out how fast the CPU ran in > the last period and convert the TSC ticks accumulated to a time > unit suitable for resource accounting. > > > The bad solution is to try to do timekeeping based on hardware > counters which are unsuitable for the purpose, the TSC being > the primary suspect here, and we will not do that. I'll bet that nobody will want to touch the scheduler, so we'll continue be stuck with inflated context switch times on SMP because we use such an expensive time source. 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? Drew