linux-kernel - Re: [PATCH 0/4] rwsem: Implement writer lock-stealing

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

Date:	Thu, 21 Feb 2013 00:50:22 +0800
From:	Michel Lespinasse <walken@...gle.com>
To:	Alex Shi <alex.shi@...el.com>
Cc:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	anton@...ba.org, hpa@...or.com, arjan@...ux.intel.com,
	a.p.zijlstra@...llo.nl, torvalds@...ux-foundation.org,
	yuanhan.liu@...ux.intel.com, dhowells@...hat.com,
	akpm@...ux-foundation.org, tglx@...utronix.de
Subject: Re: [PATCH 0/4] rwsem: Implement writer lock-stealing

On Wed, Feb 20, 2013 at 4:50 PM, Alex Shi <alex.shi@...el.com> wrote:
> I did a quick review on the patchset and tested the patches 1~3, and 1~3
> plus 4th, my patch plus 4th.
>
> The patch looks much complicated, and also goes writing slow path to
> steal locking. My patch looks quite straight and simple.
>
> This 1~3 patch has very very similar performance effect with mine.
>
> The highlight patch is the 4th, seems it can provide about ~2% aim7
> performance gain(base on both of mine or patches 1~3) on my 4S NHM EX
> machine.

Thanks for doing these measurements.

I think we can keep patches 1-2 out of this discussion as they don't
have much complexity and don't have much to do with write stealing
either.

Patch 4 is where fast path write stealing is implemented; however
there are some parts of patch 3 that I think are required - the one I
have in mind right now is when waking readers, the existing code
assumes that writers can't get the lock while it counts how many
reader locks need to be granted. There are several solutions to that -
for example you could grant the first reader lock before counting how
many more you need, but that would result in longer code than in my
proposal. Either way, I believe if you go into fixing lib/rwsem.c to
account for the possibility of fast path lock stealing you'll end up
with something very similar to my proposed patch 3...

(This is kinda how I proceeded with this series, I wrote the fastpath
lock stealing first, then I thought about what's required to support
it in the slow path)

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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/