1. 23 4月, 2016 7 次提交
    • F
      sched/fair: Correctly handle nohz ticks CPU load accounting · 1f41906a
      Frederic Weisbecker 提交于
      Ticks can happen while the CPU is in dynticks-idle or dynticks-singletask
      mode. In fact "nohz" or "dynticks" only mean that we exit the periodic
      mode and we try to minimize the ticks as much as possible. The nohz
      subsystem uses a confusing terminology with the internal state
      "ts->tick_stopped" which is also available through its public interface
      with tick_nohz_tick_stopped(). This is a misnomer as the tick is instead
      reduced with the best effort rather than stopped. In the best case the
      tick can indeed be actually stopped but there is no guarantee about that.
      If a timer needs to fire one second later, a tick will fire while the
      CPU is in nohz mode and this is a very common scenario.
      
      Now this confusion happens to be a problem with CPU load updates:
      cpu_load_update_active() doesn't handle nohz ticks correctly because it
      assumes that ticks are completely stopped in nohz mode and that
      cpu_load_update_active() can't be called in dynticks mode. When that
      happens, the whole previous tickless load is ignored and the function
      just records the load for the current tick, ignoring potentially long
      idle periods behind.
      
      In order to solve this, we could account the current load for the
      previous nohz time but there is a risk that we account the load of a
      task that got freshly enqueued for the whole nohz period.
      
      So instead, lets record the dynticks load on nohz frame entry so we know
      what to record in case of nohz ticks, then use this record to account
      the tickless load on nohz ticks and nohz frame end.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1460555812-25375-3-git-send-email-fweisbec@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1f41906a
    • F
      sched/fair: Gather CPU load functions under a more conventional namespace · cee1afce
      Frederic Weisbecker 提交于
      The CPU load update related functions have a weak naming convention
      currently, starting with update_cpu_load_*() which isn't ideal as
      "update" is a very generic concept.
      
      Since two of these functions are public already (and a third is to come)
      that's enough to introduce a more conventional naming scheme. So let's
      do the following rename instead:
      
      	update_cpu_load_*() -> cpu_load_update_*()
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul E . McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1460555812-25375-2-git-send-email-fweisbec@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      cee1afce
    • S
      sched/fair: Call cpufreq hook in additional paths · a2c6c91f
      Steve Muckle 提交于
      The cpufreq hook should be called any time the root CFS rq utilization
      changes. This can occur when a task is switched to or from the fair
      class, or a task moves between groups or CPUs, but these paths
      currently do not call the cpufreq hook.
      
      Fix this by adding the hook to attach_entity_load_avg() and
      detach_entity_load_avg().
      Suggested-by: NVincent Guittot <vincent.guittot@linaro.org>
      Signed-off-by: NSteve Muckle <smuckle@linaro.org>
      [ Added the .update_freq argument to update_cfs_rq_load_avg() to avoid a double cpufreq call. ]
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
      Cc: Juri Lelli <Juri.Lelli@arm.com>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Patrick Bellasi <patrick.bellasi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1458858367-2831-1-git-send-email-smuckle@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a2c6c91f
    • S
      sched/fair: Do not call cpufreq hook unless util changed · 41e0d37f
      Steve Muckle 提交于
      There's no reason to call the cpufreq hook if the root cfs_rq
      utilization has not been modified.
      Signed-off-by: NSteve Muckle <smuckle@linaro.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
      Cc: Juri Lelli <Juri.Lelli@arm.com>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Patrick Bellasi <patrick.bellasi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Link: http://lkml.kernel.org/r/1458606068-7476-2-git-send-email-smuckle@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      41e0d37f
    • S
      sched/fair: Move cpufreq hook to update_cfs_rq_load_avg() · 21e96f88
      Steve Muckle 提交于
      The cpufreq hook should be called whenever the root cfs_rq
      utilization changes so update_cfs_rq_load_avg() is a better
      place for it. The current location is not invoked in the
      enqueue_entity() or update_blocked_averages() paths.
      Suggested-by: NVincent Guittot <vincent.guittot@linaro.org>
      Signed-off-by: NSteve Muckle <smuckle@linaro.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
      Cc: Juri Lelli <Juri.Lelli@arm.com>
      Cc: Michael Turquette <mturquette@baylibre.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Patrick Bellasi <patrick.bellasi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1458606068-7476-1-git-send-email-smuckle@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      21e96f88
    • S
      sched/fair: Fix asym packing to select correct CPU · 1f621e02
      Srikar Dronamraju 提交于
      When asymmetric packing is set in the sched_domain and target CPU is
      busy, update_sd_pick_busiest() may not select the busiest runqueue.
      When target CPU is busy, find_busiest_group() will ignore checks for
      asym packing and may continue to load balance using the currently
      selected not-the-busiest runqueue as source runqueue.
      Selecting the busiest runqueue as source when the target CPU is busy,
      should result in achieving much better load balance.
      
      Also when target CPU is not busy and asymmetric packing is set in sd,
      select higher CPU as source CPU for load balancing.
      
      While doing this change, move the check to see if target CPU is busy
      into check_asym_packing().
      
      The extent of performance benefit from this change decreases with the
      increasing load. However there is benefit in undercommit as well as
      overcommit conditions.
      
      1. Record per second ebizzy (32 threads) on a 64 CPU power 7 box. (5 iterations)
      4.6.0-rc2
      	Testcase:         Min         Max         Avg      StdDev
      	  ebizzy:  5223767.00 10368236.00  7946971.00  1753094.76
      
      4.6.0-rc2+asym-changes
      	Testcase:         Min         Max         Avg      StdDev     %Change
      	  ebizzy:  8617191.00 13872356.00 11383980.00  1783400.89     +24.78%
      
      2. Record per second ebizzy (64 threads) on a 64 CPU power 7 box. (5 iterations)
      4.6.0-rc2
      	Testcase:         Min         Max         Avg      StdDev
      	  ebizzy:  6497666.00 18399783.00 10818093.20  4051452.08
      
      4.6.0-rc2+asym-changes
      	Testcase:         Min         Max         Avg      StdDev     %Change
      	  ebizzy:  7567365.00 19456937.00 11674063.60  4295407.48      +4.40%
      
      3. Record per second ebizzy (128 threads) on a 64 CPU power 7 box. (5 iterations)
      4.6.0-rc2
      	Testcase:         Min         Max         Avg      StdDev
      	  ebizzy: 37073983.00 40341911.00 38776241.80  1259766.82
      
      4.6.0-rc2+asym-changes
      	Testcase:         Min         Max         Avg      StdDev     %Change
      	  ebizzy: 38030399.00 41333378.00 39827404.40  1255001.86      +2.54%
      Signed-off-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1459948660-16073-1-git-send-email-srikar@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1f621e02
    • I
      84eaae15
  2. 19 4月, 2016 1 次提交
  3. 18 4月, 2016 2 次提交
  4. 17 4月, 2016 11 次提交
  5. 16 4月, 2016 7 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 2e572599
      Linus Torvalds 提交于
      Pull block fixes from Jens Axboe:
       "A few fixes for the current series. This contains:
      
         - Two fixes for NVMe:
      
           One fixes a reset race that can be triggered by repeated
           insert/removal of the module.
      
           The other fixes an issue on some platforms, where we get probe
           timeouts since legacy interrupts isn't working.  This used not to
           be a problem since we had the worker thread poll for completions,
           but since that was killed off, it means those poor souls can't
           successfully probe their NVMe device.  Use a proper IRQ check and
           probe (msi-x -> msi ->legacy), like most other drivers to work
           around this.  Both from Keith.
      
         - A loop corruption issue with offset in iters, from Ming Lei.
      
         - A fix for not having the partition stat per cpu ref count
           initialized before sending out the KOBJ_ADD, which could cause user
           space to access the counter prior to initialization.  Also from
           Ming Lei.
      
         - A fix for using the wrong congestion state, from Kaixu Xia"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: loop: fix filesystem corruption in case of aio/dio
        NVMe: Always use MSI/MSI-x interrupts
        NVMe: Fix reset/remove race
        writeback: fix the wrong congested state variable definition
        block: partition: initialize percpuref before sending out KOBJ_ADD
      2e572599
    • L
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · f3c9a1ab
      Linus Torvalds 提交于
      Pull libnvdimm fixes from Ross Zwisler:
       "Two fixes:
      
         - Fix memcpy_from_pmem() to fallback to memcpy() for architectures
           where CONFIG_ARCH_HAS_PMEM_API=n.
      
         - Add a comment explaining why we write data twice when clearing
           poison in pmem_do_bvec().
      
        This has passed a boot test on an X86_32 config, which was the
        architecture where issue #1 above was first noticed"
      
      Dan Williams adds:
       "We're giving this multi-maintainer setup a shot, so expect libnvdimm
        pull requests from either Ross or I going forward"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        libnvdimm, pmem: clarify the write+clear_poison+write flow
        pmem: fix BUG() error in pmem.h:48 on X86_32
      f3c9a1ab
    • L
      Merge tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd · 29dde7c2
      Linus Torvalds 提交于
      Pull MTD fix from Brian Norris:
       "One MTD fix for v4.6-rc4:
      
        In the v4.4 cycle, we relaxed the requirement for assigning
        mtd->owner, but we didn't remove this error case.  It's hit only
        by drivers that are both:
      
         (a) using nand_scan() directly
        and
         (b) built as modules
      
        We haven't seen explicit complaints about this (most use cases don't
        fit one or both of the above), but we should definitely not be
        BUG()'ing here"
      
      * tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd:
        mtd: nand: Drop mtd.owner requirement in nand_scan
      29dde7c2
    • L
      Merge tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc · 2fffad12
      Linus Torvalds 提交于
      Pull MMC fixes from Ulf Hansson:
       "Here are a couple of mmc fixes intended for v4.6 rc4.
      
        Regarding the fix for the regression about mmcblk device indexes.  The
        approach taken to solve the problem seems to be good enough.  There
        were some discussions around the solution, but it seems like people
        were happy about it in the end.
      
        MMC core:
         - Restore similar old behaviour when assigning mmcblk device indexes
      
        MMC host:
         - tegra: Disable UHS-I modes for Tegra124 to fix regression"
      
      * tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
        mmc: tegra: Disable UHS-I modes for Tegra124
        mmc: block: Use the mmc host device index as the mmcblk device index
      2fffad12
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · ab5f9eba
      Linus Torvalds 提交于
      Pull drm fixes from Dave Airlie:
       "This contains fixes for exynos, amdgpu, radeon, i915 and qxl.
      
        It also contains some fixes to the core drm edid parser.
      
        qxl:
         - fix for a cursor hotspot issue
      
        radeon:
         - some MST fixes that I've been running locally and make my monitor a
           bit happier
      
        exynos:
         - fix some regressions and build fixes
      
        amdgpu:
         - a couple of small fixes
      
        i915:
         - two DP MST fixes and a couple of other regression fixes
      
        Nothing too out of the ordinary or surprising at this point"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
        drm/exynos: fix a warning message
        drm/exynos: mic: fix an error code
        drm/exynos: fimd: fix broken dp_clock control
        drm/exynos: build fbdev code conditionally
        drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
        drm/exynos: fix error handling in exynos_drm_subdrv_open
        drm/amd/amdgpu: fix irq domain remove for tonga ih
        drm/i915: fix deadlock on lid open
        drm/radeon: use helper for mst connector dpms.
        drm/radeon/mst: port some MST setup code from DAL.
        drm/amdgpu: add invisible pin size statistic
        drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings
        drm/i915: Exit cherryview_irq_handler() after one pass
        drm/i915: Call intel_dp_mst_resume() before resuming displays
        drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
        drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
        drm/edid: Fix EDID Established Timings I and II
        drm/qxl: fix cursor position with non-zero hotspot
      ab5f9eba
    • L
      Merge branch 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 60ea7bb0
      Linus Torvalds 提交于
      Pull parisc ftrace fixes from Helge Deller:
       "This is (most likely) the last pull request for v4.6 for the parisc
        architecture.
      
        It fixes the FTRACE feature for parisc, which is horribly broken since
         quite some time and doesn't even compile.  This patch just fixes the
        bare minimum (it actually removes more lines than it adds), so that
        the function tracer works again on 32- and 64bit kernels.
      
        I've queued up additional patches on top of this patch which e.g. add
        the syscall tracer, but those have to wait for the merge window for
        v4.7."
      
      * 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Fix ftrace function tracer
      60ea7bb0
    • D
      libnvdimm, pmem: clarify the write+clear_poison+write flow · 0a370d26
      Dan Williams 提交于
      The ACPI specification does not specify the state of data after a clear
      poison operation.  Potential future libnvdimm bus implementations for
      other architectures also might not specify or disagree on the state of
      data after clear poison.  Clarify why we write twice.
      Reported-by: NJeff Moyer <jmoyer@redhat.com>
      Reported-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Reviewed-by: NVishal Verma <vishal.l.verma@intel.com>
      0a370d26
  6. 15 4月, 2016 12 次提交