linux-kernel - Re: [RFC] Cancellable MCS spinlock rework

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]

Message-ID: <1404420708.8764.54.camel@j-VirtualBox>
Date:	Thu, 03 Jul 2014 13:51:48 -0700
From:	Jason Low <jason.low2@...com>
To:	Waiman Long <waiman.long@...com>
Cc:	Davidlohr Bueso <davidlohr@...com>,
	Peter Zijlstra <peterz@...radead.org>,
	torvalds@...ux-foundation.org, paulmck@...ux.vnet.ibm.com,
	mingo@...nel.org, linux-kernel@...r.kernel.org, riel@...hat.com,
	akpm@...ux-foundation.org, hpa@...or.com, andi@...stfloor.org,
	James.Bottomley@...senpartnership.com, rostedt@...dmis.org,
	tim.c.chen@...ux.intel.com, aswin@...com, scott.norton@...com,
	chegu_vinod@...com
Subject: Re: [RFC] Cancellable MCS spinlock rework

On Thu, 2014-07-03 at 16:35 -0400, Waiman Long wrote:
> On 07/03/2014 02:34 PM, Jason Low wrote:
> > On Thu, 2014-07-03 at 10:09 -0700, Davidlohr Bueso wrote:
> >> On Thu, 2014-07-03 at 09:31 +0200, Peter Zijlstra wrote:
> >>> On Wed, Jul 02, 2014 at 10:30:03AM -0700, Jason Low wrote:
> >>>> Would potentially reducing the size of the rw semaphore structure by 32
> >>>> bits (for all architectures using optimistic spinning) be a nice
> >>>> benefit?
> >>> Possibly, although I had a look at the mutex structure and we didn't
> >>> have a hole to place it in, unlike what you found with the rwsem.
> >> Yeah, and currently struct rw_semaphore is the largest lock we have in
> >> the kernel. Shaving off space is definitely welcome.
> > Right, especially if it could help things like xfs inode.
> >
> 
> I do see a point in reducing the size of the rwsem structure. However, I 
> don't quite understand the point of converting pointers in the 
> optimistic_spin_queue structure to atomic_t.

Converting the pointers in the optimistic_spin_queue to atomic_t would
mean we're fully operating on atomic operations instead of using the
potentially racy cmpxchg + ACCESS_ONCE stores on the pointers.

If we're in the process of using the CPU numbers in atomic_t, I thought
we might as well fix that as well since it has actually been shown to
result in lockups on some architectures. We can then avoid needing to
implement the tricky architecture workarounds for optimistic spinning.
Wouldn't that be a "nice-have"?

Jason

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