kernel-2.6.14-rc5-rt7 - 604.62 BogoMIPS (2.6.14-rc5 - 6024.43 BogoMIPS) problem with bogometer ?
kernel-2.6.14-rc5-rt7 -- Calibrating delay using timer specific routine.. 604.62 BogoMIPS (lpj=302311)
kernel-2.6.14-rc5 -- Calibrating delay using timer specific routine.. 6024.43 BogoMIPS (lpj=12048877)
xboom
On Fri, 2005-10-28 at 18:28 -0500, art wrote:
> kernel-2.6.14-rc5-rt7 - 604.62 BogoMIPS (2.6.14-rc5 - 6024.43 BogoMIPS) problem with bogometer ?
>
> kernel-2.6.14-rc5-rt7 -- Calibrating delay using timer specific routine.. 604.62 BogoMIPS (lpj=302311)
>
> kernel-2.6.14-rc5 -- Calibrating delay using timer specific routine.. 6024.43 BogoMIPS (lpj=12048877)
Assuming this is an i386 kernel, in the timeofday patches, the __delay
function has been converted to be a simple loop based delay instead of
TSC based, since the TSC has too many potential problems.
That should explain a differing lpj value, although 10x smaller is a
little strange, so I'll dig into this on my system and see if I find
anything.
Do let me know if you see any actual changes in behavior (drivers acting
funny, etc).
thanks
-john
On Fri, 2005-10-28 at 18:28 -0500, art wrote:
> kernel-2.6.14-rc5-rt7 - 604.62 BogoMIPS (2.6.14-rc5 - 6024.43 BogoMIPS) problem with bogometer ?
>
> kernel-2.6.14-rc5-rt7 -- Calibrating delay using timer specific routine.. 604.62 BogoMIPS (lpj=302311)
>
> kernel-2.6.14-rc5 -- Calibrating delay using timer specific routine.. 6024.43 BogoMIPS (lpj=12048877)
Already been fixed and will be out in Ingo's next release. Before
high-res was activated, the ktimers was causing jiffies to go up faster
than HZ and this caused bad calculations of BogoMIPS. So for now just
sit back and relax, it doesn't harm anything right now. :)
-- Steve
On Fri, 2005-10-28 at 16:42 -0700, john stultz wrote:
> On Fri, 2005-10-28 at 18:28 -0500, art wrote:
> > kernel-2.6.14-rc5-rt7 - 604.62 BogoMIPS (2.6.14-rc5 - 6024.43 BogoMIPS) problem with bogometer ?
> >
> > kernel-2.6.14-rc5-rt7 -- Calibrating delay using timer specific routine.. 604.62 BogoMIPS (lpj=302311)
> >
> > kernel-2.6.14-rc5 -- Calibrating delay using timer specific routine.. 6024.43 BogoMIPS (lpj=12048877)
>
> Assuming this is an i386 kernel, in the timeofday patches, the __delay
> function has been converted to be a simple loop based delay instead of
> TSC based, since the TSC has too many potential problems.
>
> That should explain a differing lpj value, although 10x smaller is a
> little strange, so I'll dig into this on my system and see if I find
> anything.
>
> Do let me know if you see any actual changes in behavior (drivers acting
> funny, etc).
John,
Don't waste any time on this. This was caused by a brain fart on
Thomas' part :-) Some legacy code in ktimer_interrupt returned a enum
that was being used to update the ticks. So before high-res was
activated, the jiffies would be incremented 7 times instead of just
once. It's already been fixed. Just waiting for Ingo to release his new
patch.
-- Steve
> > That should explain a differing lpj value, although 10x smaller is a
> > little strange, so I'll dig into this on my system and see if I find
> > anything.
> >
> > Do let me know if you see any actual changes in behavior (drivers acting
> > funny, etc).
>
> John,
>
> Don't waste any time on this. This was caused by a brain fart on
> Thomas' part :-) Some legacy code in ktimer_interrupt returned a enum
> that was being used to update the ticks. So before high-res was
> activated, the jiffies would be incremented 7 times instead of just
> once. It's already been fixed. Just waiting for Ingo to release his new
> patch.
John,
Would you want to be CC'd on all ktimer related patches? This way you
wont think things like this was caused by your code.
-- Steve
On Fri, 2005-10-28 at 20:37 -0400, Steven Rostedt wrote:
> > > That should explain a differing lpj value, although 10x smaller is a
> > > little strange, so I'll dig into this on my system and see if I find
> > > anything.
> > >
> > > Do let me know if you see any actual changes in behavior (drivers acting
> > > funny, etc).
> >
> > John,
> >
> > Don't waste any time on this. This was caused by a brain fart on
> > Thomas' part :-) Some legacy code in ktimer_interrupt returned a enum
> > that was being used to update the ticks. So before high-res was
> > activated, the jiffies would be incremented 7 times instead of just
> > once. It's already been fixed. Just waiting for Ingo to release his new
> > patch.
>
> Would you want to be CC'd on all ktimer related patches? This way you
> wont think things like this was caused by your code.
I skim lkml so that's probably not necessary. This complaint just
grabbed my attention since I had made a related change in the area.
I did recall the jiffies issue once you mentioned it, but I'm not
keeping to close a watch as far as what versions of ktimers patches are
in what versions of the -rt tree (Ingo: is there a place where you have
the -rt tree broken out?)
Please do be sure to CC me if you run into any timekeeping related
problems, just so I'm sure not to miss them.
thanks!
-john
* Steven Rostedt <[email protected]> wrote:
> On Fri, 2005-10-28 at 18:28 -0500, art wrote:
> > kernel-2.6.14-rc5-rt7 - 604.62 BogoMIPS (2.6.14-rc5 - 6024.43 BogoMIPS) problem with bogometer ?
> >
> > kernel-2.6.14-rc5-rt7 -- Calibrating delay using timer specific routine.. 604.62 BogoMIPS (lpj=302311)
> >
> > kernel-2.6.14-rc5 -- Calibrating delay using timer specific routine.. 6024.43 BogoMIPS (lpj=12048877)
>
> Already been fixed and will be out in Ingo's next release. Before
> high-res was activated, the ktimers was causing jiffies to go up
> faster than HZ and this caused bad calculations of BogoMIPS. So for
> now just sit back and relax, it doesn't harm anything right now. :)
yeah. Should be fixed in 2.6.14-rt1.
Ingo