From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 14:44:51 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 29868106566B for ; Sun, 29 Jul 2012 14:44:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A1CF68FC16 for ; Sun, 29 Jul 2012 14:44:50 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3937091wgb.31 for ; Sun, 29 Jul 2012 07:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FvlgUY90zpkQng2oNl/wGgF8e0bb5eN8KZ4GNOwZ0vQ=; b=0MNgfMRDMKli/XWnNmxKCHnhnPJx1YL7+ifRO7+U8JR2HOUMF8fr6G70fq8VEg38bg /rY2DpvkB9vwmo+gbQu7SgTVCi2ngFAJ8kgY8fWvy6GqwGJD/A39UMcwYw7pfGQCStkI hfftSpNgHkMnAQ3LCkjImVzDPy1DB1aWILdvA9jdsCzfjjzvCQHS6RyQ1bwlGL3qa22q EQ+fvaghKmslCUUO72nFQtJlFRBuGeDtb84a0dGEhsdWaTCBvzOIZHEQ38riV+WI6O+1 byu5ookAanonFE8n4C7vDDrY/nhqEbwPmebaQ+GW+ErU6ZhLxBy8kJoZjs83cZgxsO2C zCKg== Received: by 10.180.98.138 with SMTP id ei10mr19745342wib.1.1343573083470; Sun, 29 Jul 2012 07:44:43 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t8sm10947334wiy.3.2012.07.29.07.44.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 07:44:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <50154C58.4060408@FreeBSD.org> Date: Sun, 29 Jul 2012 17:44:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> In-Reply-To: <20120729221526.H2941@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 14:44:51 -0000 On 29.07.2012 15:26, Bruce Evans wrote: > 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. Timecounter already has detection logic to disable TSC in cases where it is unreliable. I don't want to replicate it here. I need not precise and not synchronized by reliable and fast time source. > 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? I am not sure what reinitialization are you talking about. IIRC, there is no any waking up code for TSC. None other time counters have problems with C-states. -- Alexander Motin