[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <512FDC82.2060606@redhat.com>
Date: Thu, 28 Feb 2013 17:38:58 -0500
From: Rik van Riel <riel@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Davidlohr Bueso <davidlohr.bueso@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
"Vinod, Chegu" <chegu_vinod@...com>,
"Low, Jason" <jason.low2@...com>,
linux-tip-commits@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>, aquini@...hat.com,
Michel Lespinasse <walken@...gle.com>,
Ingo Molnar <mingo@...nel.org>,
Larry Woodman <lwoodman@...hat.com>
Subject: Re: [tip:core/locking] x86/smp: Move waiting on contended ticket
lock out of line
On 02/28/2013 04:58 PM, Linus Torvalds wrote:
> I'm not seeing any real reason the permission checking couldn't be
> done just under the RCU lock, before we get the spinlock. Except for
> the fact that the "helper" routines in ipc/util.c are written the way
> they are, so it's a layering violation. But I really think that would
> be a *reasonably* low-hanging fruit thing to do.
I could see doing the permission checks under a seq lock.
If the permissions, or any other aspect of the semaphore
array changed while we were doing our permission check,
we can simply jump back to the top of the function and
try again.
Protection against IPC_RMID (removal of the semaphore
block) can probably be done with RCU.
The ugliness of using two kinds of protection may be
necessary, since permissions can be modified in-place,
and RCU does not seem to do in-place modification...
I have been staring at the code for a bit this afternoon,
and have yet to come up with a nicer idea :(
I am always open to suggestions, though :)
> Changing the locking itself to be more fine-grained, and doing it
> across many different ipc semaphores would be a major pain. So I do
> suspect that the work Michel Lespinasse did is probably worth doing
> anyway in addition to at least trying to fix the horrible lack of
> scalability of the code a bit.
That would certainly be the easy fix.
--
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