linux-kernel - Re: [RFC PATCH 00/32] Nohz cpusets (was: Nohz Tasks)

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, 23 Aug 2011 18:36:48 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Paul Menage <paul@...lmenage.org>
Cc:	Avi Kivity <avi@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Anton Blanchard <anton@....ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Menage <menage@...gle.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Stephen Hemminger <shemminger@...tta.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 00/32] Nohz cpusets (was: Nohz Tasks)

On Sat, Aug 20, 2011 at 12:45:48AM -0700, Paul Menage wrote:
> On Thu, Aug 18, 2011 at 6:25 AM, Frederic Weisbecker <fweisbec@...il.com> wrote:
> >>
> >> Why not do it unconditionally?  That is, if all the conditions are
> >> fulfilled, disable the tick regardless of any cpuset settings.
> >
> > Because I'm not sure it's a win on every workload. This involves
> > some hooks here and there (syscall slow path), IPIs, etc...
> 
> I agree with Avi. I'd be inclined to investigate further to see if
> there are any important workloads on which it's not a win - and then
> add the extra complexity to control it from cpusets if necessary.
> Unless there's really a good reason to make it configurable, it's
> simpler to make it unconditional.

There is another things. We still need to have a CPU with the periodic
tick to maintain the jiffies and walltime progression.

Also on some workloads like HPC (I mean, that's just a personal guess),
it may make sense to also migrate the peripherals interrupts affinity
to that same CPU that keeps the periodic tick, so that we have only one
CPU handling those backrgound things and all the others can be fully
dedicated to their main task.

So with these factors combined, we need to be able to precisely choose at
least a CPU that doesn't run in adaptive nohz mode. Having that nohz cpuset
solves that issue (although I haven't forced to keep one non-nohz cpu but
I should).

Perhaps having a simple interface that defines a fixed CPU to handle
jiffies/walltime would be enough but the cpuset offers more flexibility.
I just can't test every possible workload to know if it has no downside
somewhere.

May be a global toggle in sysfs for a global adaptive nohz would be enough?
I have no idea.

Is anybody aware of any worload that involve very frequent syscalls? Like
more than 100 Hz ?
--
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/