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:	Tue, 6 Sep 2011 15:03:27 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
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>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>,
	Paul Menage <paul@...lmenage.org>
Subject: Re: [PATCH 13/32] nohz: Adaptive tick stop and restart on nohz cpuset

On Mon, Aug 29, 2011 at 05:25:36PM +0200, Peter Zijlstra wrote:
> 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.

I don't think it's necessary, that part doesn't depend on userspace hooks.
The whole thing is enabled very late anyway.

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

Ok, good.

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

Great!

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