[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100401112352.GB20577@parisc-linux.org>
Date: Thu, 1 Apr 2010 05:23:52 -0600
From: Matthew Wilcox <matthew@....cx>
To: Jamie Lokier <jamie@...reable.org>
Cc: David Howells <dhowells@...hat.com>,
Russell King <rmk@....linux.org.uk>,
Yinghai Lu <yinghai@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Rabin Vincent <rabin@....in>,
lkml <linux-kernel@...r.kernel.org>, hpa@...or.com,
penberg@...helsinki.fi, cl@...ux-foundation.org,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
linux-arch@...r.kernel.org
Subject: Re: start_kernel(): bug: interrupts were enabled early
On Thu, Apr 01, 2010 at 10:41:11AM +0100, Jamie Lokier wrote:
> David Howells wrote:
> > Russell King <rmk@....linux.org.uk> wrote:
> > > We use the standard generic kernel implementation. Is x86 different? ;)
> >
> > The optimised fast paths used on x86 rwsems don't disable interrupts.
>
> Any reason not to use the same technique for all the archs - plus the
> trick used in arch/armkernel/entry-armv.S:__kuser_cmpxchg for those
> archs which don't have atomic instructions or ll/sc?
Assuming you're talking about the __LINUX_ARM_ARCH__ < 6 + CONFIG_MMU
case, then this only works for uniprocessor machines.
> If the problem here is _only_ semaphores, and the above might make
> semaphores faster anyway, perhaps it's a solution.
You trade off a bit of overhead in the semaphore path for a bit of
overhead in the interrupt path. We probably take more sempahores than
we do interrupts, so it's probably worthwhile. Still, cmpxchg() needs
to be SMP-safe.
Realistically, this isn't something that can be done in generic code.
It has to be done in arch-specific code.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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