linux-kernel - Re: [RFC PATCH] alispinlock: acceleration from lock integration on multi-core platform

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]

Date:	Sat, 9 Jan 2016 06:44:15 +0800
From:	Ling Ma <ling.ma.program@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Waiman Long <waiman.long@....com>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Ling <ling.ml@...baba-inc.com>
Subject: Re: [RFC PATCH] alispinlock: acceleration from lock integration on
 multi-core platform

The attachment (alispinlock.tar.bz2) includes original spinlock and
alispinlock ,
we compare them on 70 cores based on kernel 4.3, the alispinlock can
improve performance upto 3x.

the link: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1035940.html
indicates when we introduce the idea for real application(user space
application  caused the bottle neck from  kernel spinlock )
the spinlock performance is improved by 1.9x (perf top -d1 also tell
us the spinlock cost time is reduced from 25% to 15%).

Appreciate your comments
Ling

2016-01-06 19:24 GMT+08:00 One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:
> On Wed, 6 Jan 2016 09:21:06 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
>
>> On Wed, Jan 06, 2016 at 09:16:43AM +0100, Peter Zijlstra wrote:
>> > On Tue, Jan 05, 2016 at 09:42:27PM +0000, One Thousand Gnomes wrote:
>> > > > It suffers the typical problems all those constructs do; namely it
>> > > > wrecks accountability.
>> > >
>> > > That's "government thinking" ;-) - for most real users throughput is
>> > > more important than accountability. With the right API it ought to also
>> > > be compile time switchable.
>> >
>> > Its to do with having been involved with -rt. RT wants to do
>> > accountability for such things because of PI and sorts.
>>
>> Also, real people really do care about latency too, very bad worst case
>> spikes to upset things.
>
> Some yes - I'm familiar with the way some of the big financial number
> crunching jobs need this. There are also people who instead care a lot
> about throughput. Anything like this needs to end up with an external API
> which looks the same whether the work is done via one thread or the other.
>
> Alan

Download attachment "alispinlock.tar.bz2" of type "application/x-bzip2" (4529 bytes)