On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
> On Tue, 30 Oct 2007, Nick Piggin wrote:
> > Is this actually a speedup on any architecture to roll your own locking
> > rather than using bit spinlock?
>
> It avoids one load from memory when allocating and the release is simply
>
On Tue, 30 Oct 2007, Nick Piggin wrote:
> Is this actually a speedup on any architecture to roll your own locking
> rather than using bit spinlock?
It avoids one load from memory when allocating and the release is simply
writing the page->flags back. Less instructions.
> I am not exactly
On Tue, 30 Oct 2007, Nick Piggin wrote:
Is this actually a speedup on any architecture to roll your own locking
rather than using bit spinlock?
It avoids one load from memory when allocating and the release is simply
writing the page-flags back. Less instructions.
I am not exactly convinced
On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
On Tue, 30 Oct 2007, Nick Piggin wrote:
Is this actually a speedup on any architecture to roll your own locking
rather than using bit spinlock?
It avoids one load from memory when allocating and the release is simply
writing the
On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
> Too many troubles with the bitlocks and we really do not need
> to do any bitops. Bitops do not effectively retrieve the old
> value which we want. So use a cmpxchg instead on the arches
> that allow it.
>
> Instead of modifying the
On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
Too many troubles with the bitlocks and we really do not need
to do any bitops. Bitops do not effectively retrieve the old
value which we want. So use a cmpxchg instead on the arches
that allow it.
Instead of modifying the page-flags
Hi,
On 10/29/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > We don't need preempt_enable for CONFIG_SMP, right?
>
> preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> It would be easier to review the actual locking changes if you did the
> SlabXXX removal in a separate patch.
There are no locking changes.
> > -static __always_inline void slab_lock(struct page *page)
> > +static __always_inline void
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> > +__release(bitlock);
>
> This needs a less generic name and maybe a comment explaining that it's
> not annotating a proper lock? Or maybe we can drop it completely?
Ah, I see that does the same thing, so strike that.
-
To unsubscribe from this
Hi Christoph,
On Sat, 27 Oct 2007, Christoph Lameter wrote:
> Too many troubles with the bitlocks and we really do not need
> to do any bitops. Bitops do not effectively retrieve the old
> value which we want. So use a cmpxchg instead on the arches
> that allow it.
> -static inline int
Hi Christoph,
On Sat, 27 Oct 2007, Christoph Lameter wrote:
Too many troubles with the bitlocks and we really do not need
to do any bitops. Bitops do not effectively retrieve the old
value which we want. So use a cmpxchg instead on the arches
that allow it.
-static inline int
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
+__release(bitlock);
This needs a less generic name and maybe a comment explaining that it's
not annotating a proper lock? Or maybe we can drop it completely?
Ah, I see that linux/bit_spinlock.h does the same thing, so strike that.
-
To
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
It would be easier to review the actual locking changes if you did the
SlabXXX removal in a separate patch.
There are no locking changes.
-static __always_inline void slab_lock(struct page *page)
+static __always_inline void slab_unlock(struct
Hi,
On 10/29/07, Christoph Lameter [EMAIL PROTECTED] wrote:
We don't need preempt_enable for CONFIG_SMP, right?
preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the #ifdefs... :-)
Too many troubles with the bitlocks and we really do not need
to do any bitops. Bitops do not effectively retrieve the old
value which we want. So use a cmpxchg instead on the arches
that allow it.
Instead of modifying the page->flags with fake atomic operations
we pass the page state as a
Too many troubles with the bitlocks and we really do not need
to do any bitops. Bitops do not effectively retrieve the old
value which we want. So use a cmpxchg instead on the arches
that allow it.
Instead of modifying the page-flags with fake atomic operations
we pass the page state as a
16 matches
Mail list logo
