1. 14 11月, 2012 2 次提交
  2. 25 9月, 2012 1 次提交
    • J
      jiffies: Remove compile time assumptions about CLOCK_TICK_RATE · b3c869d3
      John Stultz 提交于
      CLOCK_TICK_RATE is used to accurately caclulate exactly how
      a tick will be at a given HZ.
      
      This is useful, because while we'd expect NSEC_PER_SEC/HZ,
      the underlying hardware will have some granularity limit,
      so we won't be able to have exactly HZ ticks per second.
      
      This slight error can cause timekeeping quality problems
      when using the jiffies or other jiffies driven clocksources.
      Thus we currently use compile time CLOCK_TICK_RATE value to
      generate SHIFTED_HZ and NSEC_PER_JIFFIES, which we then use
      to adjust the jiffies clocksource to correct this error.
      
      Unfortunately though, since CLOCK_TICK_RATE is a compile
      time value, and the jiffies clocksource is registered very
      early during boot, there are a number of cases where there
      are different possible hardware timers that have different
      tick rates. This causes problems in cases like ARM where
      there are numerous different types of hardware, each having
      their own compile-time CLOCK_TICK_RATE, making it hard to
      accurately support different hardware with a single kernel.
      
      For the most part, this doesn't matter all that much, as not
      too many systems actually utilize the jiffies or jiffies driven
      clocksource. Usually there are other highres clocksources
      who's granularity error is negligable.
      
      Even so, we have some complicated calcualtions that we do
      everywhere to handle these edge cases.
      
      This patch removes the compile time SHIFTED_HZ value, and
      introduces a register_refined_jiffies() function. This results
      in the default jiffies clock as being assumed a perfect HZ
      freq, and allows archtectures that care about jiffies accuracy
      to call register_refined_jiffies() with the tick rate, specified
      dynamically at boot.
      
      This allows us, where necessary, to not have a compile time
      CLOCK_TICK_RATE constant, simplifies the jiffies code, and
      still provides a way to have an accurate jiffies clock.
      
      NOTE: Since this patch does not add register_refinied_jiffies()
      calls for every arch, it may cause time quality regressions
      in some cases. Its likely these will not be noticable, but
      if they are an issue, adding the following to the end of
      setup_arch() should resolve the regression:
      	register_refinied_jiffies(CLOCK_TICK_RATE)
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      b3c869d3
  3. 31 7月, 2012 1 次提交
  4. 31 3月, 2011 1 次提交
  5. 01 2月, 2011 1 次提交
  6. 31 1月, 2011 1 次提交
  7. 15 8月, 2009 1 次提交
    • M
      clocksource: Cleanup clocksource selection · f1b82746
      Martin Schwidefsky 提交于
      If a non high-resolution clocksource is first set as override clock
      and then registered it becomes active even if the system is in one-shot
      mode. Move the override check from sysfs_override_clocksource to the
      clocksource selection. That fixes the bug and simplifies the code. The
      check in clocksource_register for double registration of the same
      clocksource is removed without replacement.
      
      To find the initial clocksource a new weak function in jiffies.c is
      defined that returns the jiffies clocksource. The architecture code
      can then override the weak function with a more suitable clocksource,
      e.g. the TOD clock on s390.
      
      [ tglx: Folded in a fix from John Stultz ]
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Acked-by: NJohn Stultz <johnstul@us.ibm.com>
      Cc: Daniel Walker <dwalker@fifo99.com>
      LKML-Reference: <20090814134808.388024160@de.ibm.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f1b82746
  8. 22 4月, 2009 1 次提交
  9. 06 1月, 2009 1 次提交
  10. 21 8月, 2008 1 次提交
    • J
      clocksource: keep track of original clocksource frequency · 1aa5dfb7
      John Stultz 提交于
      The clocksource frequency is represented by
      clocksource->mult/2^(clocksource->shift).  Currently, when NTP makes
      adjustments to the clock frequency, they are made directly to the mult
      value.
      
      This has the drawback that once changed, we cannot know what the orignal
      mult value was, or how much adjustment has been applied.
      
      This property causes problems in calculating proper ntp intervals when
      switching back and forth between clocksources.
      
      This patch separates the current mult value into a mult and mult_orig
      pair.  The mult_orig value stays constant, while the ntp clocksource
      adjustments are done only to the mult value.
      
      This allows for correct ntp interval calculation and additionally lays the
      groundwork for a new notion of time, what I'm calling the monotonic-raw
      time, which is introduced in a following patch.
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1aa5dfb7
  11. 05 4月, 2007 1 次提交
    • J
      [PATCH] fix jiffies clocksource inittime · 98de9e3b
      john stultz 提交于
      In debugging a problem w/ the -rt tree, I noticed that on systems that mark
      the tsc as unstable before it is registered, the TSC would still be
      selected and used for a short period of time.  Digging in it looks to be a
      result of the mix of the clocksource list changes and my clocksource
      initialization changes.
      
      With the -rt tree, using a bad TSC, even for a short period of time can
      results in a hang at boot.  I was not able to reproduce this hang w/
      mainline, but I'm not completely certain that someone won't trip on it.
      
      This patch resolves the issue by initializing the jiffies clocksource
      earlier so a bad TSC won't get selected just because nothing else is yet
      registered.
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      98de9e3b
  12. 17 2月, 2007 1 次提交
  13. 17 10月, 2006 1 次提交
    • J
      [PATCH] i386 Time: Avoid PIT SMP lockups · 3f4a0b91
      john stultz 提交于
      Avoid possible PIT livelock issues seen on SMP systems (and reported by
      Andi), by not allowing it as a clocksource on SMP boxes.
      
      However, since the PIT may no longer be present, we have to properly handle
      the cases where SMP systems have TSC skew and fall back from the TSC.
      Since the PIT isn't there, it would "fall back" to the TSC again.  So this
      changes the jiffies rating to 1, and the TSC-bad rating value to 0.
      
      Thus you will get the following behavior priority on i386 systems:
      
      tsc		[if present & stable]
      hpet		[if present]
      cyclone		[if present]
      acpi_pm		[if present]
      pit		[if UP]
      jiffies
      
      Rather then the current more complicated:
      tsc		[if present & stable]
      hpet		[if present]
      cyclone		[if present]
      acpi_pm		[if present]
      pit		[if cpus < 4]
      tsc		[if present & unstable]
      jiffies
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3f4a0b91
  14. 27 6月, 2006 2 次提交