Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jun 2004 19:19:05 +0900
From:      YONETANI Tomokazu <qhwt+freebsd-acpi@les.ath.cx>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: cx_usage
Message-ID:  <20040619101905.GA55457@les.ath.cx>
In-Reply-To: <20040618192739.W52398@root.org>
References:  <20040616131055.GA37637@les.ath.cx> <20040618052615.GA48947@les.ath.cx> <20040618192739.W52398@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040619101905.GA55457>