summary (Re: [patch] prefer TSC over PM Timer)

From: dean gaudet (dean-list-linux-kernel_at_arctic.org)
Date: 11/17/04

  • Next message: Mike Waychison: "Re: [Request for inclusion] Filesystem in Userspace" 
    Date:	Wed, 17 Nov 2004 09:48:53 -0800 (PST)
To: john stultz <johnstul@us.ibm.com>, Dominik Brodowski <linux@dominikbrodowski.de>, "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>

    ok thanks everyone... i've been educated, and attempted to summarize the
    situation.

    if timer_pm is fixed to read the PM timer only once on non-broken systems
    then it is generally the best choice. it is only at a ~3x disadvantage
    compared to tsc/lapic in that case.

    until/unless C3 and deeper resync tsc then it's best not to default to tsc
    even on transmeta. it would require some co-ordination between timer_tsc
    and ACPI code to know if C3/etc. are enabled, i don't see that
    co-ordination there now. so it really does seem like adding "clock=tsc"
    to boot is best left to installers/users/not-the-kernel for now.

    here's my device summary:

    PIT:
    - many slow i/o accesses to read
    - works everywhere

    PM:
    - minimum one slow i/o access to read
    - measurements on a handful of systems show one PM timer read
      costs ~3x a TSC read.
    - kernel presently uses 3 reads as a bug workaround, but can be
      reduced to one read.
    - works on ~all hardware less than a few years old

    TSC:
    - fast read
    - on most systems this varies with power mgmt -- and some power mgmt
      occurs "behind-the-scenes" without kernel awareness
    - cpufreq is better and better at tracking the changes (but not on SMP?)
    - 2.6.10-rc2 disables even more behind-the-scenes power mgmt
    - stops counting in C3 (solved? with PIT/PM/RTC read coming out of C3)
    - drift possible across nodes in NUMA

    local APIC:
    - fast read (approx same as TSC)
    - enabling lapic causes some dell laptops to crash
    - stops counting in C3 (solvable with PIT/PM/RTC read coming out of C3)
    - shared with scheduler -- easy to manage today
    - can't be shared with scheduler if we add variable scheduler ticks
      (can't read CCR and write ICR atomically -- potential to drift)
    - local apic timer ticks are the best choice for scheduling on SMP
      because it allows all the CPU schedulers to be skewed and avoid
      lock conflicts.
    - drift possible across nodes in NUMA?

    HPET:
    - at the moment i know nothing about it (none of my systems have it)

    let me know if i've missed anything.

    -dean
    -
    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/

  • Next message: Mike Waychison: "Re: [Request for inclusion] Filesystem in Userspace"

    Relevant Pages

    • [patch 1/] timers: tsc using for cpu scheduling
      ... uses jiffies_64 for process priority calculation instead of Time Stamp ... Clock (TSC). ... process which provoke to memory threshing and bad cpu and cash using has ... But for scheduler purposes the value of work ...
      (Linux-Kernel)
    • Re: LTTng for 2.6.22.1-rt4 (timestamping)
      ... Every RT-kernel, has support ... hardware clock can provide. ... On X86 it will be TSC based, on ARM it can be based om ... I wonder how much time takes this timer read ...
      (Linux-Kernel)
    • Re: fixed time slices?
      ... | to finish using its time slice), and assigns a full time slice ... become ready to run, and be scheduled on a CPU, when the scheduler is ... response to a timer interrupt or a call to a wait function (maybe other ... a timer-IRQ within wahtevr delay is desired. ...
      (microsoft.public.win32.programmer.kernel)
    • Re: fixed time slices?
      ... high resolution timer(timeBeginPeriod), check ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, ... AFAIK the scheduler does not behave this way but if the scheduler planed ...
      (microsoft.public.win32.programmer.kernel)
    • Re: fixed time slices?
      ... to WFSO using an event that gets signaled just *after* WFSO ... NEVERTHELESS, as soon as a higher priority thread becomes ready to run, it ... Scheduler "ticks" only ... systems may also provide high-resolition interval timer, ...
      (microsoft.public.win32.programmer.kernel)