Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)

[john stultz <johnstul@us.ibm.com>]

On Fri, 2005-06-03 at 18:30 +0200, Andi Kleen wrote:
> On Thu, Jun 02, 2005 at 07:50:33PM -0400, Parag Warudkar wrote:
> > On Thursday 02 June 2005 19:20, john stultz wrote:
> > > Could you see if the slowness you're feeling is correlated to the
> > > acpi_pm timesource?
> > 
> > Speaking of which, the below code from arch/i386/timer_pm.c looks particularly 
> > more taxing to me - 3 times read from ioport in a loop - not sure how many 
> > time that executes. 
> > 
> > static inline u32 read_pmtmr(void)
> > {
> >         u32 v1=0,v2=0,v3=0;
> >         /* It has been reported that because of various broken
> >          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> >          * source is not latched, so you must read it multiple
> >          * times to insure a safe value is read.
> >          */
> >         do {
> >                 v1 = inl(pmtmr_ioport);
> >                 v2 = inl(pmtmr_ioport);
> >                 v3 = inl(pmtmr_ioport);
> >         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> >                         || (v3 > v1 && v3 < v2));
> > 
> > Shouldn't that loop be limited to the broken chipsets - why would correct 
> > people with correctly working chipsets carry this extra burden? (Or is it 
> > insignificant?)
> 
> It is not insignificant and makes a lot of difference. On the x86-64
> version of pmtimer I dropped it completely and so far nobody 
> complained.

Alright, I'll add a single read function and keep the triple read
function around just in case. Maybe we can use some sort of dmi
blacklist to auto-detect known trouble cases.

> However I wonder why this new time system is using pmtimer by default
> at all. That is very broken because pmtimer is one of the slowest.
> I would suggest to duplicate the time source selection I have
> in the latest x86-64 (-rc5) time.c, that is optimal for all machines
> I know about (except that you might need to add cyclone and a non TSC
> fallback for i386)

The priority values may need some tweaking. The acpi-pm timesource is
really useful on laptops that have cpufreq issues, so it has been a
higher priority then the TSC in i386 for awhile. 

How about something like this?

300 TSC 
200 HPET
200 CYCLONE
100 ACPI
050 PIT
010 JIFFIES

Then if the system has TSC issues (unsynced, cpufreq problems, etc), we
can demote the TSC's priority to 50 and it will fall back nicely without
manual intervention.

thanks
-john