From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 10:14:17 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 8D3C31065670 for ; Sun, 29 Jul 2012 10:14:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCD88FC0C for ; Sun, 29 Jul 2012 10:14:16 +0000 (UTC) Received: by weyx56 with SMTP id x56so3568576wey.13 for ; Sun, 29 Jul 2012 03:14:16 -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=0Xu7g11JGW8Ahz/LmGeCStecJAUE1idjsyPLhBtakrw=; b=dCOcnwXdLyzRiKRwEhRwk9/GFNHZKwd3QMUmJ4T4AiuFqg9XorRnTsAoMSlXxqasR9 4FEJrFBVcyN3LFJYBWCfjrmxbbSDTO2oI0IImnvPj7r8PB65EzB9VivZe4kmM0raJkqa rqdD+cWkwIMynHDj8+iTP+nhtAAOcj97ta0pxRZxDIX+cGqS2219YhAk193RsNWayPB2 lcQJO3cHNBviODs7CIn/NMnNitvXxpawxprK/6GfIrFLN5B967qh2+bxqP/HiiDxf69E xNa2NKcv9+sBbMos599xoHAOEulAAM80qIRHoVWwIjaYhsIc51BcadnJM42wHWUD11Y2 gJ9g== Received: by 10.180.100.37 with SMTP id ev5mr18568287wib.5.1343556856294; Sun, 29 Jul 2012 03:14:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t7sm14195237wix.6.2012.07.29.03.14.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 03:14:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <50150CF5.4070605@FreeBSD.org> Date: Sun, 29 Jul 2012 13:14:13 +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> In-Reply-To: <20120729175031.U2084@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 10:14:17 -0000 On 29.07.2012 11:37, Bruce Evans wrote: > 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? At least on my test system it does, even though predictably much slower then the others. > 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? 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. -- Alexander Motin