linux-kernel - Re: x86: Clean up computation of HPET .mult variables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1210126661.17132.223.camel@localhost.localdomain>
Date:	Tue, 06 May 2008 19:17:41 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	"Carlos R. Mafra" <crmafra2@...il.com>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	venkatesh.pallipadi@...el.com
Subject: Re: x86: Clean up computation of HPET .mult variables


On Tue, 2008-05-06 at 17:50 -0300, Carlos R. Mafra wrote:
> so there is no difference at all at this precision level!
> 
> Out of curiosity I computed the "exact" value by hand and
> got 292935555.9 so we can't even talk about "error" because
> the difference is in the extra digit not considered with
> the precision I used to print the results.
> 
> And if you look at the patch to do computation using 
> clocksource_hz2mult() you will see that it is uglier
> than the simple call to div_sc(), as you have to
> consider an extra variable hpet_freq and do an extra
> do_div() together with an extra rounding.
> 
> So I think you will be ok with the patch now, right? :-)

Not yet ..

I used you patch with some formatting changes and I get,

clocksource_hpet.mult   walker = 292935555
clocksource_hpet.mult my patch = 292935555

Same as yours .. just checking ;)

Now I modify the shift value from 22 to 25 and I get this,

clocksource_hpet.mult   walker = 2343484437
clocksource_hpet.mult my patch = 2343484446

I don't think this is due to rounding .. I'm not really sure why they're
different .. I would assume the clocksource_hz2mult is more correct, but
feel free to check into it if you want..

The reason I'm messing with the shift is cause 22 is actually too low..
For your period it can be 25, which would give better accuracy.

If you want to check the shift calculation I used it looks like this,

static inline u32 clocksource_hz2shift(u32 bits, u32 hz)
{
       u64 temp;

       for (; bits > 0; bits--) {
               temp = (u64) NSEC_PER_SEC << bits;
               do_div(temp, hz);
               if ((temp >> 32) == 0)
                       break;
       }
       return bits;
}

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/