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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <47BDA983.BA47.005A.0@novell.com>
Date:	Thu, 21 Feb 2008 14:40:35 -0700
From:	"Gregory Haskins" <ghaskins@...ell.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	<a.p.zijlstra@...llo.nl>, <bill.huey@...il.com>,
	<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:24 PM, in message <20080221212420.GA20953@...e.hu>,
Ingo Molnar <mingo@...e.hu> wrote: 

> hm. Why is the ticket spinlock patch included in this patchset? It just 
> skews your performance results unnecessarily. Ticket spinlocks are 
> independent conceptually, they are already upstream in 2.6.25-rc2 and 
> -rt will have them automatically once we rebase to .25.

Sorry if it was ambiguous.  I included them because we found the patch series without them can cause spikes due to the newly introduced pressure on the (raw_spinlock_t)lock->wait_lock.  You can run the adaptive-spin patches without them just fine (in fact, in many cases things run faster without them....dbench *thrives* on chaos).  But you may also measure a cyclic-test spike if you do so.  So I included them to present a "complete package without spikes".  I tried to explain that detail in the prologue, but most people probably fell asleep before they got to the end ;)

> 
> and if we take the ticket spinlock patch out of your series, the the 
> size of the patchset shrinks in half and touches only 200-300 lines of 
> code ;-) Considering the total size of the -rt patchset:
> 
>    652 files changed, 23830 insertions(+), 4636 deletions(-)
> 
> we can regard it a routine optimization ;-)

Its not the size of your LOC, but what you do with it :)

> 
> regarding the concept: adaptive mutexes have been talked about in the 
> past, but their advantage is not at all clear, that's why we havent done 
> them. It's definitely not an unambigiously win-win concept.
> 
> So lets get some real marketing-free benchmarking done, and we are not 
> just interested in the workloads where a bit of polling on contended 
> locks helps, but we are also interested in workloads where the polling 
> hurts ... And lets please do the comparisons without the ticket spinlock 
> patch ...

I'm open to suggestion, and this was just a sample of the testing we have done.  We have thrown plenty of workloads at this patch series far beyond the slides I prepared in that URL, and they all seem to indicate a net positive improvement so far.  Some of those results I cannot share due to NDA, and some I didnt share simply because I never formally collected the data like I did for these tests.  If there is something you would like to see, please let me know and I will arrange for it to be executed if at all possible.

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/