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:	Wed, 13 Feb 2013 17:31:23 -0800
From:	Michel Lespinasse <walken@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Alex Shi <alex.shi@...el.com>, 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 13, 2013 at 6:49 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Alex Shi <alex.shi@...el.com> wrote:
>
>> On 02/09/2013 10:45 AM, Michel Lespinasse wrote:
>> > This proposal implements writer lock stealing in lib/rwsem.c, just as
>> > Alex Shi's earlier proposal did for the simpler lib/rwsem-spinlock.c
>>
>> Ops, my patch in tip/urgent is for rwsem. Yuanhan's patch is
>> for rwsem-spinlock.

Sorry, my bad. Looks like an email snafu on my side - when I wanted to
save your patch to look through it with more context, I ended up
saving Yuanhan's instead.

> Your rwsem patch is queued up for v3.9, in the tip:core/locking
> tree:
>
>   3a15e0e0cdda rwsem: Implement writer lock-stealing for better scalability
>
> Michel, mind having a look at that and possibly generate a delta
> patch, if your patch has changes we should apply?

The main difference I can see is that my approach makes it possible to
steal the rwsem in a fast path, without going through the lib/rwsem.c
slow path. A few things fall out from that; most notably I had to
change the readers_only side of __rwsem_do_wake() to account with the
possibility of write lock stealing on the fast path, while Alex
doesn't since he forces write lock stealing to use the slow path.
Overall, my changes are more extensive but they also reduce the total
line count, while Alex's proposal goes the other way.

For these reasons, I think I still prefer my approach. However as
mentioned, this is not the best time for me to push it as I'll be away
for a little while. I should be able to get back to this in a couple
weeks, though.

Alex, could you go through my patch and see if there is anything you
find objectionable ? (if not about the details, at least about the
general approach of enabling writer lock stealing on the fast path)

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ