From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 09:32:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 977B616A4CE; Sat, 15 Jan 2005 09:32:42 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B5543D1D; Sat, 15 Jan 2005 09:32:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0F9Wduq000826; Sat, 15 Jan 2005 10:32:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 15 Jan 2005 18:16:06 +1100." <20050115071606.GB53545@cirb503493.alcatel.com.au> Date: Sat, 15 Jan 2005 10:32:39 +0100 Message-ID: <825.1105781559@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: [PATCH] Use local APIC timer to drive kernel clocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 09:32:42 -0000 In message <20050115071606.GB53545@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >This would seem to negate the benefit of statclock. If a process >synchronises to hardclock, and statclock is derived from hardclock >then the process will also be synchronised to statclock - and can >therefore (at least partially) circumvent the scheduler's attempts >to stop processes hogging the CPI. It is actually far worse than this. Back when hardclock() was new, the cpu would execute around 10000 instructions per tick, these days it will execute around 1000000 instructions per tick. Realistically we should have a Hz of 1MHz to maintain decent probabilities for scheduler and in particular profiling. Unfortunately, the time to service an interrupt has stayed close to constant while cpus got three orders of magnitude faster (mostly because the speed was gained by adding pipelines, caches etc) so this is utterly impossible. Results from statistical profiling is so close to meaningless these days that we might as well just remove it. statclock is a hard one, I think it is still cheaper than doing comprehensive accounting (ie: actually timing when you move between the three states) but I think the margins are getting smaller. Real computer architectures have hardware counters for that sort of stuff. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.