linux-kernel - Re: [PATCH 13/32] nohz: Adaptive tick stop and restart on nohz cpuset

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Aug 2011 17:25:36 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Anton Blanchard <anton@....ibm.com>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [PATCH 13/32] nohz: Adaptive tick stop and restart on nohz
 cpuset

On Mon, 2011-08-15 at 17:52 +0200, Frederic Weisbecker wrote:
> When a CPU is included in a nohz cpuset, try to switch
> it to nohz mode from the timer interrupt if it is the
> only non-idle task running.
> 
> Then restart the tick if necessary from the wakeup path
> if we are enqueuing a second task while the timer is stopped,
> so that the scheduler tick is rearmed.

Shouldn't you first put the syscall hooks in place before allowing the
tick to be switched off? It seems this patch is somewhat too early in
the series.

> This assumes we are using TTWU_QUEUE sched feature so I need
> to handle the off case (or actually not handle it but properly),
> because we need the adaptive tick restart and what will come
> along in further patches to be done locally and before the new
> task ever gets scheduled.

We could certainly remove that feature flag and always use it, it was
mostly a transition debug switch in case something didn't work or
performance issues were found due to this.

> I also need to look at the ARCH_WANT_INTERRUPTS_ON_CTXW case
> and the remote wakeups.

Well, ideally we'd simply get rid of that, rmk has some preliminary
patches in that direction.

--
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/