1. 27 Jul, 2017 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Drop ->get from intel_pstate structure · 22baebd4
      Rafael J. Wysocki authored
      The ->get callback in the intel_pstate structure was mostly there
      for the scaling_cur_freq sysfs attribute to work, but after commit
      f8475cef (x86: use common aperfmperf_khz_on_cpu() to calculate
      KHz using APERF/MPERF) that attribute uses arch_freq_get_on_cpu()
      provided by the x86 arch code on all processors supported by
      intel_pstate, so it doesn't need the ->get callback from the
      driver any more.
      
      Moreover, the very presence of the ->get callback in the intel_pstate
      structure causes the cpuinfo_cur_freq attribute to be present when
      intel_pstate operates in the active mode, which is bogus, because
      the role of that attribute is to return the current CPU frequency
      as seen by the hardware.  For intel_pstate, though, this is just an
      average frequency and not really current, but computed for the
      previous sampling interval (the actual current frequency may be
      way different at the point this value is obtained by reading from
      cpuinfo_cur_freq), and after commit 82b4e03e (intel_pstate: skip
      scheduler hook when in "performance" mode) the value in
      cpuinfo_cur_freq may be stale or just 0, depending on the driver's
      operation mode.  In fact, however, on the hardware supported by
      intel_pstate there is no way to read the current CPU frequency
      from it, so the cpuinfo_cur_freq attribute should not be present
      at all when this driver is in use.
      
      For this reason, drop intel_pstate_get() and clear the ->get
      callback pointer pointing to it, so that the cpuinfo_cur_freq is
      not present for intel_pstate in the active mode any more.
      
      Fixes: 82b4e03e (intel_pstate: skip scheduler hook when in "performance" mode)
      Reported-by: default avatarHuaisheng Ye <yehs1@lenovo.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      22baebd4
  2. 14 Jul, 2017 1 commit
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Correct the busy calculation for KNL · 6e34e1f2
      Srinivas Pandruvada authored
      The busy percent calculated for the Knights Landing (KNL) platform
      is 1024 times smaller than the correct busy value.  This causes
      performance to get stuck at the lowest ratio.
      
      The scaling algorithm used for KNL is performance-based, but it still
      looks at the CPU load to set the scaled busy factor to 0 when the
      load is less than 1 percent.  In this case, since the computed load
      is 1024x smaller than it should be, the scaled busy factor will
      always be 0, irrespective of CPU business.
      
      This needs a fix similar to the turbostat one in commit b2b34dfe
      (tools/power turbostat: KNL workaround for %Busy and Avg_MHz).
      
      For this reason, add one more callback to processor-specific
      callbacks to specify an MPERF multiplier represented by a number of
      bit positions to shift the value of that register to the left to
      copmensate for its rate difference with respect to the TSC.  This
      shift value is used during CPU busy calculations.
      
      Fixes: ffb81056 (intel_pstate: Avoid getting stuck in high P-states when idle)
      Reported-and-tested-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
      [ rjw: Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6e34e1f2
  3. 12 Jul, 2017 1 commit
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Fix ratio setting for min_perf_pct · d4436c0d
      Srinivas Pandruvada authored
      When the minimum performance limit percentage is set to the power-up
      default, it is possible that minimum performance ratio is off by one.
      
      In the set_policy() callback the minimum ratio is calculated by
      applying global.min_perf_pct to turbo_ratio and rounding up, but the
      power-up default global.min_perf_pct is already rounded up to the
      next percent in min_perf_pct_min().  That results in two round up
      operations, so for the default min_perf_pct one of them is not
      required.
      
      It is better to remove rounding up in min_perf_pct_min() as this
      matches the displayed min_perf_pct prior to commit c5a2ee7d
      (cpufreq: intel_pstate: Active mode P-state limits rework) in 4.12.
      
      For example on a platform with max turbo ratio of 37 and minimum
      ratio of 10, the min_perf_pct resulted in 28 with the above commit.
      Before this commit it was 27 and it will be the same after this
      change.
      
      Fixes: 1a4fe38a (cpufreq: intel_pstate: Remove max/min fractions to limit performance)
      Reported-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d4436c0d
  4. 29 Jun, 2017 2 commits
  5. 26 Jun, 2017 3 commits
    • Len Brown's avatar
      intel_pstate: skip scheduler hook when in "performance" mode · 82b4e03e
      Len Brown authored
      When the governor is set to "performance", intel_pstate does not
      need the scheduler hook for doing any calculations.  Under these
      conditions, its only purpose is to continue to maintain
      cpufreq/scaling_cur_freq.
      
      The cpufreq/scaling_cur_freq sysfs attribute is now provided by
      shared x86 cpufreq code on modern x86 systems, including
      all systems supported by the intel_pstate driver.
      
      So in "performance" governor mode, the scheduler hook can be skipped.
      This applies to both in Software and Hardware P-state control modes.
      Suggested-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82b4e03e
    • Len Brown's avatar
      intel_pstate: delete scheduler hook in HWP mode · 62611cb9
      Len Brown authored
      The cpufreq/scaling_cur_freq sysfs attribute is now provided by
      shared x86 cpufreq code on modern x86 systems, including
      all systems supported by the intel_pstate driver.
      
      In HWP mode, maintaining that value was the sole purpose of
      the scheduler hook, intel_pstate_update_util_hwp(),
      so it can now be removed.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      62611cb9
    • Len Brown's avatar
      x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF · f8475cef
      Len Brown authored
      The goal of this change is to give users a uniform and meaningful
      result when they read /sys/...cpufreq/scaling_cur_freq
      on modern x86 hardware, as compared to what they get today.
      
      Modern x86 processors include the hardware needed
      to accurately calculate frequency over an interval --
      APERF, MPERF, and the TSC.
      
      Here we provide an x86 routine to make this calculation
      on supported hardware, and use it in preference to any
      driver driver-specific cpufreq_driver.get() routine.
      
      MHz is computed like so:
      
      MHz = base_MHz * delta_APERF / delta_MPERF
      
      MHz is the average frequency of the busy processor
      over a measurement interval.  The interval is
      defined to be the time between successive invocations
      of aperfmperf_khz_on_cpu(), which are expected to to
      happen on-demand when users read sysfs attribute
      cpufreq/scaling_cur_freq.
      
      As with previous methods of calculating MHz,
      idle time is excluded.
      
      base_MHz above is from TSC calibration global "cpu_khz".
      
      This x86 native method to calculate MHz returns a meaningful result
      no matter if P-states are controlled by hardware or firmware
      and/or if the Linux cpufreq sub-system is or is-not installed.
      
      When this routine is invoked more frequently, the measurement
      interval becomes shorter.  However, the code limits re-computation
      to 10ms intervals so that average frequency remains meaningful.
      
      Discerning users are encouraged to take advantage of
      the turbostat(8) utility, which can gracefully handle
      concurrent measurement intervals of arbitrary length.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8475cef
  6. 23 Jun, 2017 2 commits
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Remove max/min fractions to limit performance · 1a4fe38a
      Srinivas Pandruvada authored
      In the current model the max/min perf limits are a fraction of current
      user space limits to the allowed max_freq or 100% for global limits.
      This results in wrong ratio limits calculation because of rounding
      issues for some user space limits.
      
      Initially we tried to solve this issue by issue by having more shift
      bits to increase precision. Still there are isolated cases where we still
      have error.
      
      This can be avoided by using ratios all together. Since the way we get
      cpuinfo.max_freq is by multiplying scaling factor to max ratio, we can
      easily keep the max/min ratios in terms of ratios and not fractions.
      
      For example:
      if the max ratio = 36
      cpuinfo.max_freq = 36 * 100000 = 3600000
      
      Suppose user space sets a limit of 1200000, then we can calculate
      max ratio limit as
      = 36 * 1200000 / 3600000
      = 12
      This will be correct for any user limits.
      
      The other advantage is that, we don't need to do any calculation in the
      fast path as ratio limit is already calculated via set_policy() callback.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1a4fe38a
    • Len Brown's avatar
      x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" · 51204e06
      Len Brown authored
      cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz
      that is otherwise reported in x86 /proc/cpuinfo "cpu MHz".
      
      There are four problems with this scheme,
      any of them is sufficient justification to delete it.
      
       1. Depending on which cpufreq driver is loaded, the behavior
          of this field is different.
      
       2. Distros complain that they have to explain to users
          why and how this field changes.  Distros have requested a constant.
      
       3. The two major providers of this information, acpi_cpufreq
          and intel_pstate, both "get it wrong" in different ways.
      
          acpi_cpufreq lies to the user by telling them that
          they are running at whatever frequency was last
          requested by software.
      
          intel_pstate lies to the user by telling them that
          they are running at the average frequency computed
          over an undefined measurement.  But an average computed
          over an undefined interval, is itself, undefined...
      
       4. On modern processors, user space utilities, such as
          turbostat(1), are more accurate and more precise, while
          supporing concurrent measurement over arbitrary intervals.
      
      Users who have been consulting /proc/cpuinfo to
      track changing CPU frequency will be dissapointed that
      it no longer wiggles -- perhaps being unaware of the
      limitations of the information they have been consuming.
      
      Yes, they can change their scripts to look in sysfs
      cpufreq/scaling_cur_frequency.  Here they will find the same
      data of dubious quality here removed from /proc/cpuinfo.
      The value in sysfs will be addressed in a subsequent patch
      to address issues 1-3, above.
      
      Issue 4 will remain -- users that really care about
      accurate frequency information should not be using either
      proc or sysfs kernel interfaces.
      They should be using using turbostat(8), or a similar
      purpose-built analysis tool.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      51204e06
  7. 19 Jun, 2017 8 commits
    • Linus Torvalds's avatar
      Linux 4.12-rc6 · 41f1830f
      Linus Torvalds authored
      41f1830f
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · 1be7107f
      Hugh Dickins authored
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1be7107f
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 1132d5e7
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "Stream of fixes has slowed down, only a few this week:
      
         - Some DT fixes for Allwinner platforms, and addition of a clock to
           the R_CCU clock controller that had been missed.
      
         - A couple of small DT fixes for am335x-sl50"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
        ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
        ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
        ARM: dts: am335x-sl50: Fix card detect pin for mmc1
        arm64: allwinner: h5: Remove syslink to shared DTSI
        ARM: sunxi: h3/h5: fix the compatible of R_CCU
      1132d5e7
    • Olof Johansson's avatar
      Merge tag 'sunxi-fixes-for-4.12' of... · a1858df9
      Olof Johansson authored
      Merge tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
      
      Allwinner fixes for 4.12
      
      A few fixes around the PRCM support that got in 4.12 with a wrong
      compatible, and a missing clock in the binding.
      
      * tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
        arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
        ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
        arm64: allwinner: h5: Remove syslink to shared DTSI
        ARM: sunxi: h3/h5: fix the compatible of R_CCU
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      a1858df9
    • Olof Johansson's avatar
      Merge tag 'omap-for-v4.12/fixes-sl50' of... · 51b6e281
      Olof Johansson authored
      Merge tag 'omap-for-v4.12/fixes-sl50' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
      
      Two fixes for am335x-sl50 to fix a boot time error
      for claiming SPI pins, and to fix a SDIO card detect
      pin for production version of the device.
      
      * tag 'omap-for-v4.12/fixes-sl50' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
        ARM: dts: am335x-sl50: Fix card detect pin for mmc1
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      51b6e281
    • Linus Torvalds's avatar
      Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost · 3696e4f0
      Linus Torvalds authored
      Pull virtio bugfix from Michael Tsirkin:
       "It turns out balloon does not handle IOMMUs correctly. We should fix
        that at some point, for now let's just disable this configuration"
      
      * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
        virtio_balloon: disable VIOMMU support
      3696e4f0
    • Linus Torvalds's avatar
      Merge branch 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux · 7d62d947
      Linus Torvalds authored
      Pull i2c fixes from Wolfram Sang:
       "Two driver bugfixes"
      
      * 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
        i2c: ismt: fix wrong device address when unmap the data buffer
        i2c: rcar: use correct length when unmapping DMA
      7d62d947
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · b3ee4edd
      Linus Torvalds authored
      Pull MIPS fixes from Ralf Baechle:
      
       - Three highmem fixes:
          + Fixed mapping initialization
          + Adjust the pkmap location
          + Ensure we use at most one page for PTEs
      
       - Fix makefile dependencies for .its targets to depend on vmlinux
      
       - Fix reversed condition in BNEZC and JIALC software branch emulation
      
       - Only flush initialized flush_insn_slot to avoid NULL pointer
         dereference
      
       - perf: Remove incorrect odd/even counter handling for I6400
      
       - ftrace: Fix init functions tracing
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: .its targets depend on vmlinux
        MIPS: Fix bnezc/jialc return address calculation
        MIPS: kprobes: flush_insn_slot should flush only if probe initialised
        MIPS: ftrace: fix init functions tracing
        MIPS: mm: adjust PKMAP location
        MIPS: highmem: ensure that we don't use more than one page for PTEs
        MIPS: mm: fixed mappings: correct initialisation
        MIPS: perf: Remove incorrect odd/even counter handling for I6400
      b3ee4edd
  8. 18 Jun, 2017 7 commits
  9. 17 Jun, 2017 7 commits
  10. 16 Jun, 2017 8 commits