From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 07:16:10 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 CAC9316A4CE; Sat, 15 Jan 2005 07:16:10 +0000 (GMT) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C6A43D31; Sat, 15 Jan 2005 07:16:09 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j0F7G7KJ010481 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 15 Jan 2005 18:16:08 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j0F7G7xP059532; Sat, 15 Jan 2005 18:16:07 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j0F7G6nX059531; Sat, 15 Jan 2005 18:16:06 +1100 (EST) (envelope-from pjeremy) Date: Sat, 15 Jan 2005 18:16:06 +1100 From: Peter Jeremy To: John Baldwin Message-ID: <20050115071606.GB53545@cirb503493.alcatel.com.au> References: <200501141546.31386.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501141546.31386.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i 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 07:16:10 -0000 On Fri, 2005-Jan-14 15:46:31 -0500, John Baldwin wrote: >I have a patch that uses the local APIC timer to drive the kernel clocks >(hardclock, statclock, and profclock) instead of the ISA timer and RTC. The >advantage of this change is that SMP machines can stop using IPIs to bounce >clock interrupts around all the time. What is the cost of an IPI compared to a hardware interrupt? > IPIs per second. Instead, I went with a simpler algorithm suggested by phk > that lets me run the timer at hz and guarantees that statclock() will be > called stathz times per second, just not evenly spaced. 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. AFAIK, the numbers 128 and 1024 are not magical to the scheduler, they are just convenient values that can be generated by the RTC. Rather than running the APIC timer at hz, you might get better detection of "rogue" processes by running the APIC timer at (say) 3000Hz with hz=apichz/3, profhz = apichz/2 (1500Hz) and stathz=apichz/23 (~130Hz) or 20 (120Hz). If it's acceptable hardclock to have significant jitter, you could further reduce synchronisation by using a fractional divisor for hz (eg hz=apichz/2.5). -- Peter Jeremy