linux-kernel - Re: [GIT PULL, RFC] Full dynticks, CONFIG_NO_HZ

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:	Sun, 5 May 2013 14:25:12 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL, RFC] Full dynticks, CONFIG_NO_HZ_FULL feature

On Sun, May 05, 2013 at 01:33:45PM -0700, Linus Torvalds wrote:
> On Sun, May 5, 2013 at 4:03 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Please consider pulling the latest timers-nohz-for-linus git tree from:
> 
> Ok, it seems to work for me, so pulled.
> 
> However, by "work for me" I mean "doesn't actually seem to make any
> difference for me". Maybe I'm odd, but the most common situation is
> either a fairly idle machine (in which case the old NOHZ did fine) or
> a fairly over-crowded one when I'm running something sufficiently
> threaded (in which case the new NOHZ_FULL doesn't do anything either).
> 
> So I really hope the "cpu has more than one running thread" case is
> getting a lot of attention. Not for 3.10, but right now it seems to
> still result in the same old 1kHz timer interrupts..
> 
> So I haven't actually found a real load where any of this makes a
> noticeable *difference*.

The workloads where we expect the most noticeable differences are
HPC workloads with short iterations and a HPC-style barrier between
each interation on the one hand and real-time workloads on the other.
My guess is that you aren't doing too much of either.

We do have some measurements taken on an early prototype of this patchset,
which are on slides 5 and 6 of:

http://linuxplumbersconf.org/2009/slides/Josh-Triplett-painless-kernel.pdf

This is for an HPC workload with a 100-microsecond iteration time.

							Thanx, Paul

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