Messages in this thread |  | | Date | Fri, 27 Jun 2008 10:12:02 +0200 | | From | Pavel Machek <> | | Subject | Re: [RFC PATCH] x86:Use cpu_khz for loops_per_jiffy calculation |
| |
Hi!
> > > > > AFAIU in calibrate_delay_direct too we measure the amount by which timer > > > > > has ticked until DELAY_CALIBRATION_TICKS amount of jiffies has passed. > > > > > So IMO the code there too assumes that there is one loop per timer > > > > > cycle ? > > > > > > > > On my machine, it reports: > > > > > > > > delay using timer specific routine.. 3661.98 BogoMIPS (lpj=7323971) > > > > ... > > > > Detected 1828.828 MHz processor. > > > > > > > > (/proc/cpuinfo) > > > > model name : Genuine Intel(R) CPU T2400 @ 1.83GHz > > > > ... > > > > cpu MHz : 1000.000 > > > How is it 1000 here ? shouldn't this be 1830.xx > > > > cpufreq effect, I believe. > > > > > > bogomips : 3657.54 > > > > > > > > So you'd break it by setting lpj (aka bogomips) to cpu_khz, right? > > > > > > We are not setting it to cpu_khz but to tsc_khz, i am assuming that in > > > this case tsc_khz will be different than cpu_khz. Can you please mail me > > > the full dmesg log. > > > > Yes, but neither cpu_khz nor tsc_khz will be 3657 bogoMips, right? > > Hi Pavel, > > Thanks for the dmesg. The HZ value that you are using on this system is > 250, right ? > > If you note the calculations > > + lpj = ((u64)tsc_khz * 1000); > > + do_div(lpj, HZ); > > We are dividing by HZ over here. So you are right in saying that tsc_khz > wont be equal to bogoMips but lpj_fine will surely be computed correct > since we do consider the HZ value.
Ok.
> Please let me know if you still have any doubts. > Or can i safely assume that you will ACK the patch ;-)
Well, I'm not expert-enough in this subsystem (nor comfortable enough with your code) to ACK it, sorry. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|  |