Re: Terrible interactivity with 2.6.0-t9-mm3

john stultz
2003-11-18T18:35:13Z

On Tue, 2003-11-18 at 08:11, Prakash K. Cheemplavam wrote:
> Prakash K. Cheemplavam wrote:
> >>
> >> After sending out multiple patches I should have been more clear. Just
> >> to avoid confusion:
> >>
> >> * the init_cpu_khz patch goes along side Thomas' patch.
> >> * the more experimental sched_clock() -> monotonic_clock() patch I just
> >> sent out for testing replaces Thomas' patch.
> >
> >
> >
> > I now tried the second one and it seems to work, tough I am not sure
> > whether the performance is as good as APCI timer deavt. It seems that
> > now CPU Hz is not shown anymore. Have a look at my dmesg:

The init_cpu_khz patch is the one that displays the calibrated CPU
frequency. The two patches listed above address independent bugs.

> So I deactivated the PM timer again and my computer is much faster
> again. Haven prime in the background taking 100% doesn't noticeable
> affect deskop performance. But I think I know where the problem lies:

Yes, Thomas pointed out that the sched_clock->monotonic_clock patch
didn't seem to work for pmtmr. I'm looking into if the pmtmr's
montonic_clock call is doing the right thing (didn't have my laptop
yesterday).

For now Thomas' patch to switch on "use_tsc" is the best fix when using
the pmtmr.

> current: c0499a60
> current->thread_info: c0528000
> Initializing CPU#0
> PID hash table entries: 4096 (order 12: 32768 bytes)
> Detected 2004.698 MHz processor.
> Using tsc for high-res timesource
>
>
> In above dmesg you can see that nothing was used as timesource, but here
> in current dmesg tsc is used. Is this normal or a bug? Need I pass a
> kernel paramtere when pm timer is enbaled?

No, its just cosmetic. Both Thomas and I have sent out a patch that
initializes the name field in the pmtmr's timer_opts struct.

See: http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/0983.html

I appreciate the testing and feedback!

thanks,
-john