linux-kernel - Re: [PATCH 00/27] Latest numa/core release, v16

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:	Wed, 21 Nov 2012 18:10:47 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH 00/27] Latest numa/core release, v16


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Nov 19, 2012 at 11:06 PM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Oh, finally a clue: you seem to have vsyscall emulation
> > overhead!
> 
> Ingo, stop it already!
> 
> This is *exactly* the kind of "blame everybody else than 
> yourself" behavior that I was talking about earlier.
> 
> There have been an absolute *shitload* of patches to try to 
> make up for the schednuma regressions THAT HAVE ABSOLUTELY 
> NOTHING TO DO WITH SCHEDNUMA, and are all about trying to work 
> around the fact that it regresses. The whole TLB optimization, 
> and now this kind of crap.
> 
> Ingo, look your code in the mirror some day, and ask yourself: 
> why do you think this fixes a "regression"?

Because scalability slowdowns are often non-linear.

So with CONFIG_NUMA_BALANCING=y we are taking a higher page 
fault rate, in exchange for a speedup.

But if some other factor further increases the page fault rate 
(such as vsyscall emulation) then the speedup can be 
non-linearly slower than the cost of the technique - washing it 
out or even turning it into an outright regression.

So, for example:

  - 10K page faults/sec from CONFIG_SCHED_BALANCING: 0.5% cost
  - 10K page faults/sec from vsyscall emu:           0.5% cost

If the two are mixed together the slowdown is non-linear:

  - 10K+10K page faults/sec overhead is not a linear 1%, but 
    might be 3%

So because I did not have an old-glibc system like David's, I 
did not know the actual page fault rate. If it is high enough 
then nonlinear effects might cause such effects.

This is an entirely valid line of inquiry IMO.

Thanks,

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