linux-kernel - Re: [PATCH [RT] 00/14] RFC

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>] [day] [month] [year] [list]

Message-Id: <47BDAD3C.BA47.005A.0@novell.com>
Date:	Thu, 21 Feb 2008 14:56:28 -0700
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>,
	"Bill Huey (hui)" <bill.huey@...il.com>
Cc:	<a.p.zijlstra@...llo.nl>, <rostedt@...dmis.org>,
	<kevin@...man.org>, <tglx@...utronix.de>, <cminyard@...sta.com>,
	<dsingleton@...sta.com>, <dwalker@...sta.com>,
	"Moiz Kohari" <MKohari@...ell.com>,
	"Peter Morreale" <PMorreale@...ell.com>,
	"Sven Dietrich" <SDietrich@...ell.com>, <dsaxena@...xity.net>,
	<ak@...e.de>, <gregkh@...e.de>, <npiggin@...e.de>,
	<linux-kernel@...r.kernel.org>, <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH [RT] 00/14] RFC - adaptive real-time locks

>>> On Thu, Feb 21, 2008 at  4:42 PM, in message <20080221214219.GA27209@...e.hu>,
Ingo Molnar <mingo@...e.hu> wrote: 

> * Bill Huey (hui) <bill.huey@...il.com> wrote:
> 
>> I came to the original conclusion that it wasn't originally worth it, 
>> but the dbench number published say otherwise. [...]
> 
> dbench is a notoriously unreliable and meaningless workload. It's being 
> frowned upon by the VM and the IO folks.

I agree...its a pretty weak benchmark.  BUT, it does pound on dcache_lock and therefore was a good demonstration of the benefits of lower-contention overhead.  Also note we also threw other tests in that PDF if you scroll to the subsequent pages.

> If that's the only workload 
> where spin-mutexes help, and if it's only a 3% improvement [of which it 
> is unclear how much of that improvement was due to ticket spinlocks], 
> then adaptive mutexes are probably not worth it.

Note that the "3%" figure being thrown around was from a single patch within the series.  We are actually getting a net average gain of 443% in dbench.  And note that the number goes *up* when you remove the ticketlocks.  The ticketlocks are there to prevent latency spikes, not improve throughput.

Also take a look at the hackbench numbers which are particularly promising.   We get a net average gain of 493% faster for RT10 based hackbench runs.  The kernel build was only a small gain, but it was all gain nonetheless.  We see similar results for any other workloads we throw at this thing.  I will gladly run any test requested to which I have the ability to run, and I would encourage third party results as well.

> 
> I'd not exclude them fundamentally though, it's really the numbers that 
> matter. The code is certainly simple enough (albeit the .config and 
> sysctl controls are quite ugly and unacceptable - adaptive mutexes 
> should really be ... adaptive, with no magic constants in .configs or 
> else).

We can clean this up, per your suggestions.

> 
> But ... i'm somewhat sceptic, after having played with spin-a-bit 
> mutexes before.

Its very subtle to get this concept to work.  The first few weeks, we were getting 90% regressions ;)  Then we had a breakthrough and started to get this thing humming along quite nicely.

Regards,
-Greg

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