lkml.org 
[lkml]   [2005]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)
    From
    Date
    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


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-06-03 20:32    [W:4.093 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site