linux-kernel - [PATCH 0/2] tick: NO_HZ_FULL: get rid of unnecessary interruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri,  9 May 2014 14:10:21 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	tglx@...utronix.de
Cc:	linaro-kernel@...ts.linaro.org, linux-kernel@...r.kernel.org,
	fweisbec@...il.com, arvind.chauhan@....com,
	preeti@...ux.vnet.ibm.com, khilman@...aro.org,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: [PATCH 0/2] tick: NO_HZ_FULL: get rid of unnecessary interruption

This happened for me during my NO_HZ_FULL testing on isolated CPU, but may
happen otherwise as well.

When the last htimer of a CPU is cancelled (For example: for NO_HZ_FULL when
expires == KTIME_MAX), we do not SHUTDOWN the event device. And because of that
we will get interrupted unnecessarily on the isolated core as event device will
interrupt as per the last value it is configured with.

The implementation of event device's driver may make it worse. For example:
drivers/clocksource/arm_arch_timer.c disables the event device only on
SHUTDOWN/UNUSED requests in set-mode. Otherwise, it will keep giving interrupts
at tick interval even if hrtimer_interrupt() didn't reprogram tick (When expires
== KTIME_MAX). And so we will keep getting interrupt every few milliseconds. To
confirm this I added a small hack in hrtimer.c [1] and got these results [2] as
soon as the CPU got isolated with NO_HZ_FULL and cpusets.

Probably the right solution to fix this is to disable the event device for such
cases, i.e. expires == KTIME_MAX and restart it later when required. This will
get rid of unnecessary interruption which can be avoided.

Tested over 3.15-rc4 on ARM Exynos5250 (Dual A15) board.

NOTE: Current implementation of NO_HZ_FULL has a limitation of 1 second and so
we might never end up cancelling sched_timer. I was using Kevin's debug patch:
https://lkml.org/lkml/2013/12/17/649, with which I am able to get expires to
KTIME_MAX and so ended up cancelling hrtimer.

[1] http://pastebin.com/MhDdawVd
[2] http://pastebin.com/5U5FBbTW

Viresh Kumar (2):
  hrtimer: reprogram event for expires=KTIME_MAX in
    hrtimer_force_reprogram()
  tick: SHUTDOWN event-dev if no events are required for KTIME_MAX

 include/linux/clockchips.h |  1 +
 kernel/hrtimer.c           |  3 +--
 kernel/time/tick-oneshot.c | 14 +++++++++++++-
 3 files changed, 15 insertions(+), 3 deletions(-)

-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/