1. 21 May, 2019 1 commit
  2. 10 May, 2019 1 commit
    • Viresh Kumar's avatar
      cpufreq: Call transition notifier only once for each policy · df24014a
      Viresh Kumar authored
      
      
      Currently, the notifiers are called once for each CPU of the policy->cpus
      cpumask. It would be more optimal if the notifier can be called only
      once and all the relevant information be provided to it. Out of the 23
      drivers that register for the transition notifiers today, only 4 of them
      do per-cpu updates and the callback for the rest can be called only once
      for the policy without any impact.
      
      This would also avoid multiple function calls to the notifier callbacks
      and reduce multiple iterations of notifier core's code (which does
      locking as well).
      
      This patch adds pointer to the cpufreq policy to the struct
      cpufreq_freqs, so the notifier callback has all the information
      available to it with a single call. The five drivers which perform
      per-cpu updates are updated to use the cpufreq policy. The freqs->cpu
      field is redundant now and is removed.
      
      Acked-by: David S. Miller <davem@davemloft.net> (sparc)
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      df24014a
  3. 25 Apr, 2019 1 commit
    • Rafael J. Wysocki's avatar
      x86: tsc: Rework time_cpufreq_notifier() · c208ac8f
      Rafael J. Wysocki authored
      
      
      There are problems with running time_cpufreq_notifier() on SMP
      systems.
      
      First off, the rdtsc() called from there runs on the CPU executing
      that code and not necessarily on the CPU whose sched_clock() rate is
      updated which is questionable at best.
      
      Second, in the cases when the frequencies of all CPUs in an SMP
      system are always in sync, it is not sufficient to update just
      one of them or the set associated with a given cpufreq policy on
      frequency changes - all CPUs in the system should be updated and
      that would require more than a simple transition notifier.
      
      Note, however, that the underlying issue (the TSC rate depending on
      the CPU frequency) has not been present in hardware shipping for the
      last few years and in quite a few relevant cases (acpi-cpufreq in
      particular) running time_cpufreq_notifier() will cause the TSC to
      be marked as unstable anyway.
      
      For this reason, make time_cpufreq_notifier() simply mark the TSC
      as unstable and give up when run on SMP and only try to carry out
      any adjustments otherwise.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      c208ac8f
  4. 22 Mar, 2019 1 commit
  5. 06 Nov, 2018 1 commit
    • Daniel Vacek's avatar
      x86/tsc: Make calibration refinement more robust · a786ef15
      Daniel Vacek authored
      
      
      The threshold in tsc_read_refs() is constant which may favor slower CPUs
      but may not be optimal for simple reading of reference on faster ones.
      
      Hence make it proportional to tsc_khz when available to compensate for
      this. The threshold guards against any disturbance like IRQs, NMIs, SMIs
      or CPU stealing by host on guest systems so rename it accordingly and
      fix comments as well.
      
      Also on some systems there is noticeable DMI bus contention at some point
      during boot keeping the readout failing (observed with about one in ~300
      boots when testing). In that case retry also the second readout instead of
      simply bailing out unrefined. Usually the next second the readout returns
      fast just fine without any issues.
      Signed-off-by: default avatarDaniel Vacek <neelx@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Link: https://lkml.kernel.org/r/1541437840-29293-1-git-send-email-neelx@redhat.com
      a786ef15
  6. 14 Oct, 2018 1 commit
  7. 02 Oct, 2018 2 commits
    • Mike Travis's avatar
      x86/tsc: Fix UV TSC initialization · 2647c43c
      Mike Travis authored
      The recent rework of the TSC calibration code introduced a regression on UV
      systems as it added a call to tsc_early_init() which initializes the TSC
      ADJUST values before acpi_boot_table_init().  In the case of UV systems,
      that is a necessary step that calls uv_system_init().  This informs
      tsc_sanitize_first_cpu() that the kernel runs on a platform with async TSC
      resets as documented in commit 341102c3 ("x86/tsc: Add option that TSC
      on Socket 0 being non-zero is valid")
      
      Fix it by skipping the early tsc initialization on UV systems and let TSC
      init tests take place later in tsc_init().
      
      Fixes: cf7a63ef
      
       ("x86/tsc: Calibrate tsc only once")
      Suggested-by: default avatarHedi Berriche <hedi.berriche@hpe.com>
      Signed-off-by: default avatarMike Travis <mike.travis@hpe.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarRuss Anderson <rja@hpe.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@hpe.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Russ Anderson <russ.anderson@hpe.com>
      Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
      Cc: Xiaoming Gao <gxm.linux.kernel@gmail.com>
      Cc: Rajvi Jingar <rajvi.jingar@intel.com>
      Link: https://lkml.kernel.org/r/20181002180144.923579706@stormcage.americas.sgi.com
      2647c43c
    • Peter Zijlstra's avatar
      x86/cpu: Sanitize FAM6_ATOM naming · f2c4db1b
      Peter Zijlstra authored
      Going primarily by:
      
        https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
      
      
      
      with additional information gleaned from other related pages; notably:
      
       - Bonnell shrink was called Saltwell
       - Moorefield is the Merriefield refresh which makes it Airmont
      
      The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
      
        for i in `git grep -l FAM6_ATOM` ; do
      	sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g'		\
      		-e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/'		\
      		-e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g'		\
      		-e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g'	\
      		-e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g'		\
      		-e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g'	\
      		-e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g'	\
      		-e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g'	\
      		-e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g'	\
      		-e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g'		\
      		-e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
        done
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: dave.hansen@linux.intel.com
      Cc: len.brown@intel.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f2c4db1b
  8. 06 Sep, 2018 1 commit
  9. 03 Sep, 2018 1 commit
  10. 30 Jul, 2018 1 commit
  11. 19 Jul, 2018 6 commits
    • Pavel Tatashin's avatar
      x86/tsc: Make use of tsc_calibrate_cpu_early() · 8dbe4385
      Pavel Tatashin authored
      
      
      During early boot enable tsc_calibrate_cpu_early() and switch to
      tsc_calibrate_cpu() only later. Do this unconditionally, because it is
      unknown what methods other cpus will use to calibrate once they are
      onlined.
      
      If by the time tsc_init() is called tsc frequency is still unknown do only
      pit_hpet_ptimer_calibrate_cpu() to calibrate, as this function contains the
      only methods wich have not been called and tried earlier.
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-27-pasha.tatashin@oracle.com
      8dbe4385
    • Pavel Tatashin's avatar
      x86/tsc: Split native_calibrate_cpu() into early and late parts · 03821f45
      Pavel Tatashin authored
      
      
      During early boot TSC and CPU frequency can be calibrated using MSR, CPUID,
      and quick PIT calibration methods. The other methods PIT/HPET/PMTIMER are
      available only after ACPI is initialized.
      
      Split native_calibrate_cpu() into early and late parts so they can be
      called separately during early and late tsc calibration.
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-26-pasha.tatashin@oracle.com
      03821f45
    • Pavel Tatashin's avatar
      x86/tsc: Use TSC as sched clock early · 4763f03d
      Pavel Tatashin authored
      
      
      All prerequesites for enabling TSC as sched clock early in the boot
      process are available now:
      
       - Early attempt of TSC calibration
      
       - Early availablity of static branch patching
      
      If TSC frequency can be established in the early calibration, enable the
      static key which switches sched clock to use TSC.
      
      [ tglx: Massaged changelog ]
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-22-pasha.tatashin@oracle.com
      4763f03d
    • Pavel Tatashin's avatar
      x86/tsc: Initialize cyc2ns when tsc frequency is determined · e2a9ca29
      Pavel Tatashin authored
      
      
      cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data
      structure.
      
      Currently, the setup code for c2ns data for every possible CPU goes through
      the same sequence of calculations as for the boot CPU, but is based on the
      same tsc frequency as the boot CPU, and thus this is not necessary.
      
      Initialize the boot cpu when tsc frequency is determined. Copy the
      calculated data from the boot CPU to the other CPUs in tsc_init().
      
      In addition do the following:
      
       - Remove unnecessary zeroing of c2ns data by removing cyc2ns_data_init()
      
       - Split set_cyc2ns_scale() into two functions, so set_cyc2ns_scale() can be
         called when system is up, and wraps around __set_cyc2ns_scale() that can
         be called directly when system is booting but avoids saving restoring
         IRQs and going and waking up from idle.
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-21-pasha.tatashin@oracle.com
      e2a9ca29
    • Pavel Tatashin's avatar
      x86/tsc: Calibrate tsc only once · cf7a63ef
      Pavel Tatashin authored
      
      
      During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(),
      and the second time in tsc_init().
      
      Rename tsc_early_delay_calibrate() to tsc_early_init(), and rework it so
      the calibration is done only early, and make tsc_init() to use the values
      already determined in tsc_early_init().
      
      Sometimes it is not possible to determine tsc early, as the subsystem that
      is required is not yet initialized, in such case try again later in
      tsc_init().
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-20-pasha.tatashin@oracle.com
      cf7a63ef
    • Pavel Tatashin's avatar
      x86/tsc: Redefine notsc to behave as tsc=unstable · fe9af81e
      Pavel Tatashin authored
      
      
      Currently, the notsc kernel parameter disables the use of the TSC by
      sched_clock(). However, this parameter does not prevent the kernel from
      accessing tsc in other places.
      
      The only rationale to boot with notsc is to avoid timing discrepancies on
      multi-socket systems where TSC are not properly synchronized, and thus
      exclude TSC from being used for time keeping. But that prevents using TSC
      as sched_clock() as well, which is not necessary as the core sched_clock()
      implementation can handle non synchronized TSC based sched clocks just
      fine.
      
      However, there is another method to solve the above problem: booting with
      tsc=unstable parameter. This parameter allows sched_clock() to use TSC and
      just excludes it from timekeeping.
      
      So there is no real reason to keep notsc, but for compatibility reasons the
      parameter has to stay. Make it behave like 'tsc=unstable' instead.
      
      [ tglx: Massaged changelog ]
      Signed-off-by: default avatarPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDou Liyang <douly.fnst@cn.fujitsu.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-12-pasha.tatashin@oracle.com
      fe9af81e
  12. 02 May, 2018 2 commits
  13. 17 Apr, 2018 1 commit
    • Xiaoming Gao's avatar
      x86/tsc: Prevent 32bit truncation in calc_hpet_ref() · d3878e16
      Xiaoming Gao authored
      
      
      The TSC calibration code uses HPET as reference. The conversion normalizes
      the delta of two HPET timestamps:
      
          hpetref = ((tshpet1 - tshpet2) * HPET_PERIOD) / 1e6
      
      and then divides the normalized delta of the corresponding TSC timestamps
      by the result to calulate the TSC frequency.
      
          tscfreq = ((tstsc1 - tstsc2 ) * 1e6) / hpetref
      
      This uses do_div() which takes an u32 as the divisor, which worked so far
      because the HPET frequency was low enough that 'hpetref' never exceeded
      32bit.
      
      On Skylake machines the HPET frequency increased so 'hpetref' can exceed
      32bit. do_div() truncates the divisor, which causes the calibration to
      fail.
      
      Use div64_u64() to avoid the problem.
      
      [ tglx: Fixes whitespace mangled patch and rewrote changelog ]
      Signed-off-by: default avatarXiaoming Gao <newtongao@tencent.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Cc: peterz@infradead.org
      Cc: hpa@zytor.com
      Link: https://lkml.kernel.org/r/38894564-4fc9-b8ec-353f-de702839e44e@gmail.com
      d3878e16
  14. 16 Mar, 2018 1 commit
    • Rajvi Jingar's avatar
      x86/tsc: Convert ART in nanoseconds to TSC · fc804f65
      Rajvi Jingar authored
      
      
      Device drivers use get_device_system_crosststamp() to produce precise
      system/device cross-timestamps. The PHC clock and ALSA interfaces, for
      example, make the cross-timestamps available to user applications.  On
      Intel platforms, get_device_system_crosststamp() requires a TSC value
      derived from ART (Always Running Timer) to compute the monotonic raw and
      realtime system timestamps.
      
      Starting with Intel Goldmont platforms, the PCIe root complex supports the
      PTM time sync protocol. PTM requires all timestamps to be in units of
      nanoseconds. The Intel root complex hardware propagates system time derived
      from ART in units of nanoseconds performing the conversion as follows:
      
           ART_NS = ART * 1e9 / <crystal frequency>
      
      When user software requests a cross-timestamp, the system timestamps
      (generally read from device registers) must be converted to TSC by the
      driver software as follows:
      
          TSC = ART_NS * TSC_KHZ / 1e6
      
      This is valid when CPU feature flag X86_FEATURE_TSC_KNOWN_FREQ is set
      indicating that tsc_khz is derived from CPUID[15H]. Drivers should check
      whether this flag is set before conversion to TSC is attempted.
      Suggested-by: default avatarChristopher S. Hall <christopher.s.hall@intel.com>
      Signed-off-by: default avatarRajvi Jingar <rajvi.jingar@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Link: https://lkml.kernel.org/r/1520530116-4925-1-git-send-email-rajvi.jingar@intel.com
      fc804f65
  15. 14 Jan, 2018 5 commits
  16. 10 Nov, 2017 1 commit
  17. 07 Nov, 2017 1 commit
  18. 16 Oct, 2017 1 commit
  19. 25 Sep, 2017 2 commits
  20. 22 Jun, 2017 1 commit
  21. 23 May, 2017 1 commit
  22. 15 May, 2017 6 commits
    • Peter Zijlstra's avatar
      sched/clock: Remove unused argument to sched_clock_idle_wakeup_event() · ac1e843f
      Peter Zijlstra authored
      
      
      The argument to sched_clock_idle_wakeup_event() has not been used in a
      long time. Remove it.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ac1e843f
    • Peter Zijlstra's avatar
      x86/tsc, sched/clock, clocksource: Use clocksource watchdog to provide stable sync points · b421b22b
      Peter Zijlstra authored
      
      
      Currently we keep sched_clock_tick() active for stable TSC in order to
      keep the per-CPU state semi up-to-date. The (obvious) problem is that
      by the time we detect TSC is borked, our per-CPU state is also borked.
      
      So hook into the clocksource watchdog and call a method after we've
      found it to still be stable.
      
      There's the obvious race where the TSC goes wonky between finding it
      stable and us running the callback, but closing that is too much work
      and not really worth it, since we're already detecting TSC wobbles
      after the fact, so we cannot, per definition, fully avoid funny clock
      values.
      
      And since the watchdog runs less often than the tick, this is also an
      optimization.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b421b22b
    • Peter Zijlstra's avatar
      x86/tsc: Feed refined TSC calibration into sched_clock() · aa7b630e
      Peter Zijlstra authored
      
      
      For the (older) CPUs that still need the refined TSC calibration, also
      update the sched_clock() rate.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      aa7b630e
    • Peter Zijlstra's avatar
      x86/tsc: Fix sched_clock() sync · 615cd033
      Peter Zijlstra authored
      
      
      While looking through the code I noticed that we initialize the cyc2ns
      fields with a different cycle value for each CPU, resulting in a
      slightly different 0 point for each CPU.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      615cd033
    • Peter Zijlstra's avatar
      x86/tsc: Remodel cyc2ns to use seqcount_latch() · 59eaef78
      Peter Zijlstra authored
      
      
      Replace the custom multi-value scheme with the more regular
      seqcount_latch() scheme. Along with scrapping a lot of lines, the latch
      scheme is better documented and used in more places.
      
      The immediate benefit however is not being limited on the update side.
      The current code has a limit where the writers block which is hit by
      future changes.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      59eaef78
    • Peter Zijlstra's avatar
      x86/tsc: Provide 'tsc=unstable' boot parameter · 8309f86c
      Peter Zijlstra authored
      
      
      Since the clocksource watchdog will only detect broken TSC after the
      fact, all TSC based clocks will likely have observed non-continuous
      values before/when switching away from TSC.
      
      Therefore only thing to fully avoid random clock movement when your
      BIOS randomly mucks with TSC values from SMI handlers is reporting the
      TSC as unstable at boot.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8309f86c
  23. 23 Mar, 2017 1 commit