The rwsem count has been converted to an atomic variable and we
now directly use atomic_long_add() and atomic_long_add_return()
on the count, so we can remove the asm-generic implementation of
rwsem_atomic_add() and rwsem_atomic_update().
Signed-off-by: Jason Low
---
include/asm-generic/rwsem.h
;
> This patch updates the ifdefs and comments to architecturally neutral
> versions.
>
> Cc: Arnd Bergmann
> Acked-by: Richard Kuo
> Signed-off-by: Will Deacon
> ---
>
> Hi Arnd,
>
> Any chance you could queue this for 3.15 please? It means I can easily
> move
versions.
Cc: Arnd Bergmann
Acked-by: Richard Kuo
Signed-off-by: Will Deacon
---
Hi Arnd,
Any chance you could queue this for 3.15 please? It means I can easily
move arm64 over to the asm-generic rwsem implementation afterwards.
Cheers,
Will
include/asm-generic/rwsem.h | 10 +-
1
On Fri, Feb 28, 2014 at 12:50:06PM +, Peter Hurley wrote:
> On 02/28/2014 07:13 AM, Will Deacon wrote:
> > diff --git a/include/asm-generic/rwsem.h b/include/asm-generic/rwsem.h
> > index 603a0a11e592..2b6401f9e428 100644
> > --- a/include/asm-generic/rwsem.h
> > +++ b/include/asm-generic/rwsem
On 02/28/2014 07:13 AM, Will Deacon wrote:
On Thu, Feb 27, 2014 at 05:28:24AM +, Davidlohr Bueso wrote:
On Fri, 2014-02-21 at 17:22 +, Will Deacon wrote:
The asm-generic rwsem implementation directly acceses sem->cnt when
performing a __down_read_trylock operation. Whilst this
On Thu, Feb 27, 2014 at 05:28:24AM +, Davidlohr Bueso wrote:
> On Fri, 2014-02-21 at 17:22 +, Will Deacon wrote:
> > The asm-generic rwsem implementation directly acceses sem->cnt when
> > performing a __down_read_trylock operation. Whilst this is probably safe
> >
On Thu, Feb 27, 2014 at 05:28:24AM +, Davidlohr Bueso wrote:
> On Fri, 2014-02-21 at 17:22 +, Will Deacon wrote:
> > The asm-generic rwsem implementation directly acceses sem->cnt when
> > performing a __down_read_trylock operation. Whilst this is probably safe
> >
On Fri, 2014-02-21 at 17:22 +, Will Deacon wrote:
> The asm-generic rwsem implementation directly acceses sem->cnt when
> performing a __down_read_trylock operation. Whilst this is probably safe
> on all architectures, we should stick to the atomic_long_* API and use
> atomic_lo
On Fri, Feb 21, 2014 at 05:22:27PM +, Will Deacon wrote:
> asm-generic/rwsem.h used to live under arch/powerpc. During its
> liberation to common code, a few references to its former home where
> preserved, in particular the definition of RWSEM_ACTIVE_MASK is
> predicated on CONFIG_PPC64.
>
>
asm-generic/rwsem.h used to live under arch/powerpc. During its
liberation to common code, a few references to its former home where
preserved, in particular the definition of RWSEM_ACTIVE_MASK is
predicated on CONFIG_PPC64.
This patch updates the ifdefs and comments to architecturally neutral
ver
The asm-generic rwsem implementation directly acceses sem->cnt when
performing a __down_read_trylock operation. Whilst this is probably safe
on all architectures, we should stick to the atomic_long_* API and use
atomic_long_read instead.
Signed-off-by: Will Deacon
---
include/asm-gene
This patch enables the use of generic rwsem spinlocks
to support RT on sparc64
Acked-by: David S. Miller
Signed-off-by: Allen Pais
---
arch/sparc/Kconfig |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6787bd3..554995d
>
> davem won't apply this because the PREEMPT_RT symbol is not available
> upstream. I referred to patch two+.
Yes, I thought it'd be good get a review from him.
- Allen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
On 12/16/2013 05:07 AM, Allen Pais wrote:
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -179,12 +179,10 @@ config NR_CPUS
> source kernel/Kconfig.hz
>
> config RWSEM_GENERIC_SPINLOCK
> - bool
> - default y if SPARC32
> + def_bool PREEMPT_RT_FULL
>
> config RWSEM_XCHG
Signed-off-by: Allen Pais
---
arch/sparc/Kconfig |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6787bd3..554995d 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -179,12 +179,10 @@ config NR_CPUS
source kerne
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Look at how the counter works in the XADD-based version. That's the way
> > it is *because* I'm using XADD. That's quite limiting.
>
> Not really. ll/sc architectures "emulate" xadd the same as they would
> emulate a spinlock. There is nothing suboptim
On Tue, Dec 05, 2006 at 08:36:22PM +, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Either approach works, and one is better than the current two approaches.
>
> >From one point of view that's true. But from other points of view, it isn't.
>
> > > have be implemented b
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Either approach works, and one is better than the current two approaches.
>From one point of view that's true. But from other points of view, it isn't.
> > have be implemented by spinlock on some archs, and so your approach is
> > really not optimal in s
On Mon, Dec 04, 2006 at 12:55:16PM +, David Howells wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Move to an architecture independent rwsem implementation, using the
> > better of the two rwsem implementations (ie. the one which doesn't
> > take a spinlock to take an uncontested rwsem)
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Move to an architecture independent rwsem implementation, using the
> better of the two rwsem implementations (ie. the one which doesn't
> take a spinlock to take an uncontested rwsem) as a basis. This gives
> us a single rwsem design instead of two.
Sigh.
On Mon, Dec 04, 2006 at 11:06:07AM +0100, Nick Piggin wrote:
> (resending with correct ML addresses, sorry)
>
> Hi,
>
> This patch needs review and testing from the architecture guys, but
> I would like to consider it because of the obvious maintenance benefits.
Hah, very important detail: patch
Linus Torvalds wrote:
> For i386 and i486, there is no reason to try to maintain a complex fast
> case. The machines are unquestionably going away - we should strive to not
> burden them unnecessarily, but we should _not_ try to save two cycles.
...
> Icache is also precious on the 386, which has
On Mon, Apr 23, 2001 at 06:27:23PM -0500, Bob McElrath wrote:
> Well, take that back, I just got it to hang. Again, this is 2.4.4pre3
> with alpha-numa-3 and rwsem-generic-4. I saw it upon starting mozilla.
> I also saw some scary filesystem errors that may or may not be related:
> Apr 23 18
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> > I'm at 2 days uptime now, and have not seen the process-table-hang.
> > Looks like this fixed it. Previously I would get a hang in the first
> > day or so. I'm using your alpha-numa-3
On Sat, 21 Apr 2001, Russell King wrote:
>
> Erm, spin_lock()? What if up_read or up_write gets called from interrupt
> context (is this allowed)?
Currently that is not allowed.
We allow it for regular semaphores, but not for rw-semaphores.
We may some day have to revisit that issue, but I s
On Sat, Apr 21, 2001 at 03:37:42PM +0100, Russell King wrote:
> On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > > I would suggest the following:
> > >
> > > - the generic semaphores should use the lock that
On Sat, Apr 21, 2001 at 03:37:05PM +0100, [EMAIL PROTECTED] wrote:
> Andrea Arcangeli writes:
> > That it is allowed by my generic code that does spin_lock_irq in down_* and
> > spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
^
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > I would suggest the following:
> >
> > - the generic semaphores should use the lock that already exists in the
> >wait-queue as the semaphore spinlock.
>
>
Andrea Arcangeli writes:
> That it is allowed by my generic code that does spin_lock_irq in down_* and
> spin_lock_irqsave in up_* but it's disallowed by the weaker semantics of the
> generic and x86 semaphores 2.4.4pre[2345] (or + David's last patch).
Hang on, who's code is in 2.4.4-pre5? It cl
On Sat, Apr 21, 2001 at 03:17:37PM +0100, Russell King wrote:
> On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> > On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > > I would suggest the following:
> > >
> > > - the generic semaphores should use the lock that
On Sat, Apr 21, 2001 at 04:03:27PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> > I would suggest the following:
> >
> > - the generic semaphores should use the lock that already exists in the
> >wait-queue as the semaphore spinlock.
>
>
On Fri, Apr 20, 2001 at 04:45:32PM -0700, Linus Torvalds wrote:
> I would suggest the following:
>
> - the generic semaphores should use the lock that already exists in the
>wait-queue as the semaphore spinlock.
Ok, that is what my generic code does.
> - the generic semaphores should _not
On Fri, 20 Apr 2001, Andrea Arcangeli wrote:
>
> While dropping the list_empty check to speed up the fast path I faced the same
> complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the wheel I
> read how the problem was solved in 2.4.4pre4.
I would suggest the following:
- the
On Fri, Apr 20, 2001 at 09:23:47AM +0100, David Howells wrote:
> Andrea seems to have changed his mind on the non-inlining in the generic case.
I changed my mind because if you benchmark the fast path you will do it without
running out of icache (basically only down_* and up_* will be in the icac
On Fri, 20 Apr 2001, David Howells wrote:
>
> The file should only be used for the 80386 and maybe early 80486's where
> CMPXCHG doesn't work properly, everything above that can use the XADD
> implementation.
Why are those not using the generic files? The generic code is obviously
more maintain
On Fri, Apr 20, 2001 at 03:42:15AM +0200, Andrea Arcangeli wrote:
> I'm uncertain if I should drop the list_empty() check from the fast path and if
While dropping the list_empty check to speed up the fast path I faced the same
complexity of the 2.4.4pre4 lib/rwsem.c and so before reinventing the
> About the benchmark you wrote it looks good measure to me, thanks.
As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I think Andrea is right. Although this file seems to be entirely
> old-fashioned and should never be used, right?
I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of times)
On Fri, Apr 20, 2001 at 12:28:09AM +0100, D . W . Howells wrote:
> I benchmarked four different environments:
>
> (1) 2.4.4-pre3 + Andrea's generic rwsem patch
> (2) 2.4.4-pre4 using XADD to implement the rwsems
> (3) same as (2) but with a tweak to make rw
ipset. All the tests were run
in runlevel 3 with no other applications running.
I benchmarked four different environments:
(1) 2.4.4-pre3 + Andrea's generic rwsem patch
(2) 2.4.4-pre4 using XADD to implement the rwsems
(3) same as (2) but with a tweak to make rwsem_w
On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> I'm at 2 days uptime now, and have not seen the process-table-hang.
> Looks like this fixed it. Previously I would get a hang in the first
> day or so. I'm using your alpha-numa-3 and rwsem-generic-4 against
> 2.4.4pre3.
good, than
Bob McElrath [[EMAIL PROTECTED]] wrote:
> Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> >
> > So please try to reproduce the hang with 2.4.4pre3 with those two
> > patches applied:
> >
> >
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
> >
On Wed, Apr 18, 2001 at 12:54:41AM +0100, D . W . Howells wrote:
> > It is 36bytes. and on 64bit archs the difference is going to be less.
>
> You're right - I can't add up (must be too late at night), and I was looking
> at wait_queue not wait_queue_head. I suppose that means my implementation
> It is 36bytes. and on 64bit archs the difference is going to be less.
You're right - I can't add up (must be too late at night), and I was looking
at wait_queue not wait_queue_head. I suppose that means my implementations
are then 20 and 16 bytes respectively.
On 64-bit archs the difference
On Tue, Apr 17, 2001 at 10:48:02PM +0100, D . W . Howells wrote:
> I disagree... you want such primitives to be as efficient as possible. The
> whole point of having asm/.h files is that you can stuff them full of
> dirty tricks specific to certain architectures.
Of course you always have t
On Tue, Apr 17, 2001 at 11:29:23PM +0200, Christoph Hellwig wrote:
> Yes! All the objects in export-objs only get additional depencies in
> Rules.make - but if they do not get compiled at all that depencies won't
> matter either. All other makefile work this way, btw.
ok thanks for the confirm.
> I am sure ppc couldn't race (at least unless up_read/up_write were excuted
> from irq/softnet context and that never happens in 2.4.4pre3, see below ;).
This is not actually using the rwsem code I wrote at the moment.
> And incidentally the above is what (I guess Richard) did on the alpha a
Hi Andrea,
In article <[EMAIL PROTECTED]> you wrote:
> I didn't exported rwsem.c if CONFIG_RWSEM_GENERIC is set to n as suggested
> by Christoph yet because the old code couldn't be buggy and it's not obvious to
> me that the other way around is correct (Christoph are you sure we can export an
>
On Tue, Apr 17, 2001 at 08:18:57PM +0100, D . W . Howells wrote:
> Andrea,
>
> > As said the design of the framework to plugin per-arch rwsem implementation
> > isn't flexible enough and the generic spinlocks are as well broken, try to
> > use them if you can (yes I tried that for the alpha, it
Andrea,
> As said the design of the framework to plugin per-arch rwsem implementation
> isn't flexible enough and the generic spinlocks are as well broken, try to
> use them if you can (yes I tried that for the alpha, it was just a mess and
> it was more productive to rewrite than to fix).
Ha
__DECLARE_RWSEM_GENERIC(name,RW_LOCK_BIAS-1)
^^
#define DECLARE_RWSEM_WRITE_LOCKED(name) __DECLARE_RWSEM_GENERIC(name,0)
> > My generic rwsem should be also cleaner and faster than the generic ones in
> > 2.4.4pre3 and they can be turned off compl
e) and I cannot reproduce the hang any
> longer.
Can you supply a test case that demonstrates it not working?
> My generic rwsem should be also cleaner and faster than the generic ones in
> 2.4.4pre3 and they can be turned off completly so an architecture can really
> takeove
Thanks a lot, andrea,
this patch (I only applied the rwsem one) finally fixes
the rwsem compile problem with gcc-3.0-20010417.
Now I can get a working kernel ;-)
-mirabilos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
In article <[EMAIL PROTECTED]> you wrote:
> My generic rwsem should be also cleaner and faster than the generic ones in
> 2.4.4pre3 and they can be turned off completly so an architecture can really
> takeover with its own asm implementation (while with the 2.4.4pre3 design this
Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
>
> So please try to reproduce the hang with 2.4.4pre3 with those two
> patches applied:
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/peop
in C that is now
adpoted by the ppc port (I added some scalability and locking optimization),
and made them generic dropping all the rwsem stuff that is been included into
2.4.4pre[23] (the generic rwsemaphores in those kernels is broken, try to use
them in other archs or x86 and you will notice) a
56 matches
Mail list logo
