linux-kernel - Re: [RFC PATCH 15/15] nohz

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, 21 Dec 2010 02:24:20 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Anton Blanchard <anton@....ibm.com>,
	Tim Pepper <lnxninja@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH 15/15] nohz_task: Procfs interface

On Mon, Dec 20, 2010 at 05:16:39PM +0100, Peter Zijlstra wrote:
> On Mon, 2010-12-20 at 16:57 +0100, Frederic Weisbecker wrote:
> 
> > Should I?
> 
> Well yes, this interface of explicitly marking a task and cpu as
> task_no_hz is kinda restrictive and useless.

Yeah indeed. I did the mistake to focus on the HPC specific worflow,
or rather what I imagine as the HPC specific workflow: a single task
per cpu doing intensive work.

But this should also work without even tweaks on the affinity or so.

> When I run 4 cpu-bound tasks on a quad-core I shouldn't have to do
> anything to benefit from this.

Yeah exactly. If the scheduler load balancer does the appropriate
share between CPUs, having only one task running on each should
happen often enough.

And let the user optimize that by playing with irq and task affinity.

We still need to do the echo 1 > /proc/pid/nohz though.
 
> I don't see why having this cpumask is restricting you in any way,
> user-space tasks don't migrate around, that all happens in kernel space.

The cpumask is useful to find unbound targets and for RCU to know if it
should send the specific IPI. Ah and also to keep at least one
CPU that has no nohz task to handle the timekeeping.

- For the unbound targets, we are discussing that elsewhere, that's one
reason for which we need to keep a CPU without nohz task, so that it
can handle those unbound timers. But if there is no such CPU, we can
just fallback as we did before.

- RCU can unconditonally send the specific IPI which can fallback into
executing the simple resched IPI callback if no nohz task is runnning
on the CPU.

- The last reason to keep at least one CPU without nohz task is then
the timekeeping. But again, if every CPU has a nohz task, we can
fallback to a random one

> Also, I'm not quite happy with the pure userspace restriction, but at
> least I see why you did that event though you didn't mention that.

What do you mean? The fact that kernel threads can not be nohz task?
--
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/