From owner-freebsd-current@FreeBSD.ORG Sun May 20 22:37:28 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B683D16A469; Sun, 20 May 2007 22:37:28 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A304B13C465; Sun, 20 May 2007 22:37:28 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id D29891A3C1C; Sun, 20 May 2007 15:38:25 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C1CD25140A; Sun, 20 May 2007 18:37:27 -0400 (EDT) Date: Sun, 20 May 2007 18:37:27 -0400 From: Kris Kennaway To: takawata@freeBSD.org, njl@FreeBSD.org, current@FreeBSD.org Message-ID: <20070520223727.GB44666@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: HPET vs other timers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 20 May 2007 22:37:28 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I recently noticed that the default timecounter on my system has changed to HPET (formerly it used ACPI-fast by default): kern.timecounter.choice: TSC(800) ACPI-fast(1000) HPET(2000) i8254(0) dummy(-1000000)OA This is of particular interest to me because the timecounter speed and serialization requirements are the major performance factor for things like LOCK_PROFILING (in the default configuration this inserts at least one time counter read into every kernel lock operation). This is an interesting test because time counters that require some kind of explicit or implicit serialization tend to serialize all lock operations and dramatically reduce performance. In addition there may be different overheads to timecounter reads. The following is a comparison of a multiprocessor benchmark (it is not important what it is, except that "higher is better") performance on an 8-core system with LOCK_PROFILING active: no LOCK_PROFILING 24559.36 (baseline) TSC 19627.16 ACPI-fast 4633.02 HPET 2917.85 i8254 panic :( [1] i.e. HPET is actually slower than all the other (working ;) timecounters in this configuration. Can you provide some more justification of why HPET has the highest quality factor and is appropriate to be used as the preferred timecounter? Kris [1] Fatal double fault cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: enter: panic NMI ISA 20, EISA ff NMI ... going to debugger [thread pid 847 tid 100163 ] Stopped at lapic_ipi_raw: pushq %rbp db> wh Tracing pid 847 tid 100163 td 0xffffff008c02f000 lapic_ipi_raw() at lapic_ipi_raw dmapbase() at 0xffffff008c02f000 --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGUM2nWry0BWjoQKURAnXLAKCXFrQoZkuvMUX+WqIOOuiFAFXdpwCdHisr ZpRLBWZZO6gy5jLBW4f6HS0= =Bd/l -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ--