linux-kernel - Re: [RFC PATCH 0/2] ipc: do not hold ipc lock more than necessary

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:	Fri, 1 Mar 2013 17:32:48 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Davidlohr Bueso <davidlohr.bueso@...com>
Cc:	Rik van Riel <riel@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Vinod, Chegu" <chegu_vinod@...com>,
	"Low, Jason" <jason.low2@...com>,
	linux-tip-commits@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>, aquini@...hat.com,
	Michel Lespinasse <walken@...gle.com>,
	Ingo Molnar <mingo@...nel.org>,
	Larry Woodman <lwoodman@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] ipc: do not hold ipc lock more than necessary

On Fri, Mar 1, 2013 at 4:16 PM, Davidlohr Bueso <davidlohr.bueso@...com> wrote:
>
> With Rik's semop-multi.c microbenchmark we can see the following
> results:

Ok, that certainly looks very good.

> +  59.40%            a.out  [kernel.kallsyms]  [k] _raw_spin_lock
> +  17.47%            a.out  [kernel.kallsyms]  [k] _raw_spin_lock

I had somewhat high expectations, but that's just better than I really
hoped for. Not only is the percentage down, it's down for the case of
a much smaller number of overall cycle cost, so it's a really big
reduction in contention spinning.

Of course, contention will come back and overwhelm you at *some*
point, but it seems the patches certainly moved the really bad
contention point out some way..

> +   6.14%            a.out  [kernel.kallsyms]  [k] sys_semtimedop
> +  11.08%            a.out  [kernel.kallsyms]  [k] sys_semtimedop
> While the _raw_spin_lock time is drastically reduced, others do increase.
> This results in an overall speedup of ~1.7x regarding ops/sec.

Actually, the others don't really increase. Sure, the *percentages* go
up, but that's just because it has to add up to 100% in the end. So
it's not that you're moving costs from one place to another - the 1.7x
speedup is the real reduction in costs, and then that 6.14% -> 11.08%
"growth" is really nothing but that (and yes, 1.7 x 6.14 really does
get pretty close).

So nothing really got slower, despite the percentages going up.

Looks good to me. Of course, the *real* issue is if this is a win on
real code too. And I bet it is, it just won't be quite as noticeable.
But if anything, real code is likely to have less contention to begin
with, because it has more things going on outside of the spinlocks. So
it should see an improvement, but not nearly the kind of improvement
you quote here.

Although your 800-user swingbench numbers were pretty horrible, so
maybe that case can improve by comparable amounts in the bad cases.

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