From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 19 10:19:08 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82B8716A4CE for ; Sat, 19 Jun 2004 10:19:08 +0000 (GMT) Received: from les.ath.cx (12.41.244.43.ap.yournet.ne.jp [43.244.41.12]) by mx1.FreeBSD.org (Postfix) with SMTP id A668543D31 for ; Sat, 19 Jun 2004 10:19:07 +0000 (GMT) (envelope-from qhwt+freebsd-acpi@les.ath.cx) Received: (qmail 55776 invoked by uid 1000); 19 Jun 2004 10:19:05 -0000 Date: Sat, 19 Jun 2004 19:19:05 +0900 From: YONETANI Tomokazu To: Nate Lawson Message-ID: <20040619101905.GA55457@les.ath.cx> References: <20040616131055.GA37637@les.ath.cx> <20040618052615.GA48947@les.ath.cx> <20040618192739.W52398@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040618192739.W52398@root.org> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@freebsd.org Subject: Re: cx_usage X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 10:19:08 -0000 On Fri, Jun 18, 2004 at 07:27:57PM -0700, Nate Lawson wrote: > On Fri, 18 Jun 2004, YONETANI Tomokazu wrote: > > On Wed, Jun 16, 2004 at 10:10:55PM +0900, YONETANI Tomokazu wrote: > > > What do you think about the following changes? > > > > > > - print 100% instead of 99% when there's only 1 Cx state, and 0% > > > when the sum is zero. > > > - two digits from fractional part of each percentage are shown; > > > my Laptop PC barely enters into C3 state and hw.acpi.cpu.cx_usage > > > is almost always "0% 99% 0%" after revision 1.39. it's now shown as > > > "0.00% 99.96% 0.03%" > > > > Actually, cpu_cx_stats[i] * 100 may not fit in u_int and would print > > incorrect value as values grow. Please try this instead. > > Thank you. I committed this with minor changes. Thanks. But I found myself stupid: whole = cpu_cx_stats[i] * 100; cpu_cx_stats[i] needs a cast into u_int64_t, otherwise multiplication is still performed as 32bit-integer and will overflow before assigned to `whole', and using u_int64_t variables is worthless. I tend to assume that there's an automatic upgrade of precision to that of the left-hand side operand, but it's pretty wrong. I should have noticed this while testing the patch if I kept the laptop turned on a bit longer. I'm sorry.