Skip to content

L
linux
Switch branch/tag
  1. 26 Apr, 2016 3 commits
    • Daniel Lezcano's avatar
      cpuidle: Replace ktime_get() with local_clock() · e93e59ce
      Daniel Lezcano authored 
      The ktime_get() can have a non negligeable overhead, use local_clock()
instead.

In order to test the difference between ktime_get() and local_clock(),
a quick hack has been added to trigger, via debugfs, 10000 times a
call to ktime_get() and local_clock() and measure the elapsed time.

Then the average value, the min and max is computed for each call.

From userspace, the test above was called 100 times every 2 seconds.

So, ktime_get() and local_clock() have been called 1000000 times in
total.

The results are:

ktime_get():
============
 * average: 101 ns (stddev: 27.4)
 * maximum: 38313 ns
 * minimum: 65 ns

local_clock():
==============
 * average: 60 ns (stddev: 9.8)
 * maximum: 13487 ns
 * minimum: 46 ns

The local_clock() is faster and more stable.

Even if it is a drop in the ocean, changing the ktime_get() by the
local_clock() allows to save 80ns at idle time (entry + exit). And
in some circumstances, especially when there are several CPUs racing
for the clock access, we save tens of microseconds.

The idle duration resulting from a diff is converted from nanosec to
microsec. This could be done with integer division (div 1000) - which is
an expensive operation or by 10 bits shifting (div 1024) - which is fast
but unprecise.

The following table gives some results at the limits.

 ------------------------------------------
|   nsec   |   div(1000)   |   div(1024)   |
 ------------------------------------------
|   1e3    |        1 usec |      976 nsec |
 ------------------------------------------
|   1e6    |     1000 usec |      976 usec |
 ------------------------------------------
|   1e9    |  1000000 usec |   976562 usec |
 ------------------------------------------

There is a linear deviation of 2.34%. This loss of precision is acceptable
in the context of the resulting diff which is used for statistics. These
ones are processed to guess estimate an approximation of the duration of the
next idle period which ends up into an idle state selection. The selection
criteria takes into account the next duration based on large intervals,
represented by the idle state's target residency.

The 2^10 division is enough because the approximation regarding the 1e3
division is lost in all the approximations done for the next idle duration
computation.
Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
[ rjw: Subject ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e93e59ce
    • Rafael J. Wysocki's avatar
      Merge back earlier cpuidle changes for v4.7. · f0fb0dd0
      Rafael J. Wysocki authored
      f0fb0dd0
    • Rafael J. Wysocki's avatar
      Merge branch 'cpuidle/4.7' of http://git.linaro.org/people/daniel.lezcano/linux into tmp · b5ebbcdb
      Rafael J. Wysocki authored 
      Pull ARM cpuidle changes for v4.7 from Daniel Lezcano.

* 'cpuidle/4.7' of http://git.linaro.org/people/daniel.lezcano/linux:
  drivers: firmware: psci: use const and __initconst for psci_cpuidle_ops
  soc: qcom: spm: Use const and __initconst for qcom_cpuidle_ops
  ARM: cpuidle: constify return value of arm_cpuidle_get_ops()
  ARM: cpuidle: add const qualifier to cpuidle_ops member in structures
      b5ebbcdb
  3. 24 Apr, 2016 2 commits
  5. 23 Apr, 2016 10 commits
  7. 22 Apr, 2016 24 commits
  9. 21 Apr, 2016 1 commit
    • cpaul@redhat.com's avatar
      drm/dp/mst: Validate port in drm_dp_payload_send_msg() · deba0a2a
      cpaul@redhat.com authored 
      With the joys of things running concurrently, there's always a chance
that the port we get passed in drm_dp_payload_send_msg() isn't actually
valid anymore. Because of this, we need to make sure we validate the
reference to the port before we use it otherwise we risk running into
various race conditions. For instance, on the Dell MST monitor I have
here for testing, hotplugging it enough times causes us to kernel panic:

[drm:intel_mst_enable_dp] 1
[drm:drm_dp_update_payload_part2] payload 0 1
[drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
[drm:intel_hpd_irq_handler] digital hpd port B - short
[drm:intel_dp_hpd_pulse] got hpd irq on port B - short
[drm:intel_dp_check_mst_status] got esi 00 10 00
[drm:drm_dp_update_payload_part2] payload 1 1
general protection fault: 0000 [#1] SMP
…
Call Trace:
 [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
 [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
 [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
 [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
 [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
 [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
 [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
 [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
 [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
 [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
 [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
 [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
 [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
 [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
 [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
 [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
RIP  [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]

Which occurs because of the hotplug event shown in the log, which ends
up causing DRM's dp helpers to drop the port we're updating the payload
on and panic.

CC: stable@vger.kernel.org
Signed-off-by: default avatarLyude <cpaul@redhat.com>
Reviewed-by: default avatarDavid Airlie <airlied@linux.ie>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      deba0a2a
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7