From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 08:38:01 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0DD1065676; Sun, 29 Jul 2012 08:38:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 18FC88FC0A; Sun, 29 Jul 2012 08:38:00 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6T8bpGw030794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 18:37:52 +1000 Date: Sun, 29 Jul 2012 18:37:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <5014DD00.3000307@FreeBSD.org> Message-ID: <20120729175031.U2084@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 08:38:01 -0000 On Sun, 29 Jul 2012, Alexander Motin wrote: > With ACPI timer gradually becoming one of slowest in the system, is there > some reason to use it directly in acpi_cpu_idle()? I've made a patch: > http://people.freebsd.org/~mav/sleep_time.patch > to use binuptime() instead. Using even HPET from system time counter (not > even speaking about TSC) that significantly improves performance on some > workloads if this code is not covered by MWAIT optimization in cpu_idle(). Does it work with a perverse timecounter like the i8254 work? The user is permitted to switch to any supported timecounter. There are other perverse ones: - ACPI. This seems to be unavailable if the system thinks ACPI-fast works. Bug. The user should be able to downgrade to it if ACPI-fast in fact doesn't work. Since it reads the hardware more than once, it is much slower than direct use of the hardware. - ACPI-fast. Even this is perverse. It only reads the hardware once, but goes through many software layers. binuptime() is more accurate than uncalibrated scaling. Is accuracy required? If not, the CPU ticker might work, and is faster than HPET, and and is not under user control for perverse settings. It normally reduces to readtsc() with no serializing instruction even in proposed changes. This is good enough for process times (not very good) and depends on the CPU not changing. Its calibration is very accurate (similar to timecounters) modulo bugs, but not always up to date. Bruce