From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 12:26:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F317A106564A; Sun, 29 Jul 2012 12:26:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 339F78FC17; Sun, 29 Jul 2012 12:26:19 +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 mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6TCQFQm003777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 22:26:18 +1000 Date: Sun, 29 Jul 2012 22:26:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <50150CF5.4070605@FreeBSD.org> Message-ID: <20120729221526.H2941@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@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 12:26:21 -0000 On Sun, 29 Jul 2012, Alexander Motin wrote: > On 29.07.2012 11:37, Bruce Evans wrote: > ... >> binuptime() is more accurate than uncalibrated scaling. Is accuracy >> required? > > Accuracy is not required at all. +-20% is not a problem. > >> 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. > > Problem with ticker that it may stop during idle periods, and idle is exactly > what happens here. Unlike timecounter usage here we don't need CPU > synchronicity, but we need it working during deep sleeps. The ticker is the same as the timecounter in many cases of interest. If the TSC stops then it cannot be used for timecounting unless timecounting is reinitialized. Timecounting should be reinitialized after deep sleeps, but you say you need it to work during deep sleeps. I wouldn't trust timecounters for some time after waking up after a deep sleep. If their clock stopped then the times read might only be very out of date. If their clock didn't stop, then they might have wrapped or otherwise overflowed and the times read would be garbage. Is there any locking or ordering to prevent them being used before they are reinitialized? Bruce