On Tue, Jul 10, 2007 at 07:26:10PM -0700, Christoph Lameter wrote:
> On Wed, 11 Jul 2007, Nick Piggin wrote:
>
> > BTW. some advanced congestion algorithms like HBO may find these ticket
> > locks useful because you can see immediately how many CPUs are contending
> > the lock, and spinners know h
On Wed, 11 Jul 2007, Nick Piggin wrote:
> BTW. some advanced congestion algorithms like HBO may find these ticket
> locks useful because you can see immediately how many CPUs are contending
> the lock, and spinners know how many CPUs are in front of them. That info
> could be fed into the spin bac
On Tue, Jul 10, 2007 at 01:52:47PM -0700, Christoph Lameter wrote:
> On Sun, 8 Jul 2007, Andi Kleen wrote:
>
> > I would say the main drawback of switchable and queued locks
> > would be also that they require a larger spinlock_t thus increasing
> > cache usage
>
> Right. Zoran Radovic has shown
On Sun, 8 Jul 2007, Andi Kleen wrote:
> I would say the main drawback of switchable and queued locks
> would be also that they require a larger spinlock_t thus increasing
> cache usage
Right. Zoran Radovic has shown that queued locks are inferior
to other approaches. The best approach that he f
On Mon, 9 Jul 2007, Linus Torvalds wrote:
>
> There are no issues with the 255-CPU cap on 32-bit x86. It's just not
> relevant to anybody. So the _only_ thing that matters is speed and to a
> secondary degree size.
..of course, from a pure speed standpoint, the "lock dec" one seems to
be the
On Mon, 9 Jul 2007, Davide Libenzi wrote:
>
> The always-lfence instruction in vadd-lock really is painfull though.
> If numbers are close, and given that spinlock size considering structure
> alignments should not matter much, wouldn't it be better to use a double
> short and remove the 256 C
On Mon, 9 Jul 2007, Linus Torvalds wrote:
> On Mon, 9 Jul 2007, Davide Libenzi wrote:
> >
> > So in this box, and in this test, the double-short Z-lock seems faster
> > than a double-byte. I've no idea why, since it uses two ops more and an
> > extra register.
>
> At this kind of level, the ex
On Mon, 9 Jul 2007, Davide Libenzi wrote:
>
> So in this box, and in this test, the double-short Z-lock seems faster
> than a double-byte. I've no idea why, since it uses two ops more and an
> extra register.
At this kind of level, the exact instruction scheduling can make a big
difference.
On Mon, 9 Jul 2007, Davide Libenzi wrote:
> #define ZLOCK_INIT(l) (l)[0] = 0, (l)[1] = 0
> static inline void zlock(short *lock)
> {
> __asm__ __volatile__ ("lock ; xaddl %%eax, %0\n\t"
> "mov %%eax, %%ebx\n\t"
> "shr $16, %%ebx\n\t"
>
On Sun, 8 Jul 2007, Nick Piggin wrote:
> I made some tests of the queued spinlock code using userspace test code on
> 64-bit processors. I believe the xadd based code no longer has any theoretical
> memory ordering problems.
>
> The tests were done on 3 different architectures of different speeds
On Sun, 8 Jul 2007, Andi Kleen wrote:
>
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > I made some tests of the queued spinlock code using userspace test code on
> > 64-bit processors. I believe the xadd based code no longer has any
> > theoretical
> > memory ordering problems.
>
> Linus, the
On Sun, Jul 08, 2007 at 01:18:10PM +0200, Andi Kleen wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > I made some tests of the queued spinlock code using userspace test code on
> > 64-bit processors. I believe the xadd based code no longer has any
> > theoretical
> > memory ordering problem
Nick Piggin <[EMAIL PROTECTED]> writes:
> I made some tests of the queued spinlock code using userspace test code on
> 64-bit processors. I believe the xadd based code no longer has any theoretical
> memory ordering problems.
Linus, the background of this is that on 8 socket Opteron systems
the c
13 matches
Mail list logo
