On Sat, 6 Aug 2005 13:37, Gabriel Devenyi wrote:
> After conducting some further research I've determined that cool n quiet
> has no effect on this "bug" if you can call it that. With the system
> running in init 1, and cool n quiet disabled in the bios, a sleep(N>0)
> results in the run_time value afterwards always being nearly the same value
> of ~995000 on my athlon64, similarly, my server an athlon-tbird, which
> definitely has no power saving features, hovers at ~1496000
We know that sleep(1) doesn't give us accurate sleep of 1 second, only close
to it limited by Hz, schedule_timeout and how busy the kernel otherwise is.
> Obviously since these values are nowhere near 10000, the loops_per_ms
> benchmark runs forever, has anyone seen/read about sleep on amd machines
> doing something odd? Can anyone else with an amd machine confirm this
> behavior? Con: should we attempt to get the attention of LKML to see why
> amd chips act differently?
None of that matters because the timing is done during a non sleep period
using the real time clock:
start_time = get_nsecs(&myts);
burn_loops(loops);
run_time = get_nsecs(&myts) - start_time;
So the time spent in sleep(1) should be irrelevant to the timing of
loops_per_ms. Something else is happening to the cpu _during_ the sleep that
makes the next lot of loops take a different length of time. That's the bit I
haven't been able to figure out.
Cheers,
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
