If you order each byte by priority, then you just reinvent the SCSI
arbitration procedure or something close to that. ;-)
I expect the reinvention of the wheel very soon. :o)
(Don't mind, please, it is a joke. You proposal may be fine).
Gérard.
On Tue, 30 Nov 1999, Ingo Molnar wrote:
> the attached patch implements a new spinlock variant, which is 2 bytes
> shorter (thus less icache footprint) per lock/unlock than the previous
> variant. The inline part of the kernel is smaller by 1654 bytes. Speed is
> the same. Patch is against pre3-2.3.30 and works just fine for me.
>
>
> there is also another spinlock variant which i came up with: it does not
> use any LOCK-ed instruction. This is for up to 8 CPU systems (easy to be
> extended to 16 CPUs, or simplified to 4 CPUs). Every spinlock is NR_CPUS
> bytes, each byte represents one CPU. (%%esi) and 4(%%esi) is the spinlock
> in the 8-CPU case. Eg. on CPU3 the following code is executed:
>
>
> movb $1, 3(%%esi) # spin_lock
> movl 4(%%esi), %%edx
> addl (%%esi), %%edx
> cmpl $0x01000000, %%edx
> je slow_path
>
> ...
>
> movb $0, 3(%%esi) # spin_unlock
>
> the method uses the fact that 8-bit writes and 32-bit reads are guaranteed
> to be atomic by Intel, and that Processor Ordering is enforced. By the
> time we add (%%esi) and 4(%%esi), all other CPUs' potential stores must
> have been observed, and thus we get into the slow path if there was any
> write to any of the two words. And we get into the 'lock acquired' path if
> and only if we were the only store to all 8 bytes. (The slow path is
> reasonably straightforward.)
>
> the above (together with necessery glue instructions) executes in about 15
> cycles on a Xeon, while current spinlocks execute in 22 cycles. (~9 cycles
> out of those 15 cycles are due to a pipeline stall caused by the partial
> byte depencency.)
>
> i'm not at all convinced this is worth the trouble though, but it's an
> interesting and LOCK-less variant nevertheless ;)
>
> -- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/