Messages in this thread | | | Date | Wed, 1 Dec 1999 00:20:30 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: [patch] new spinlock variant, spinlock-2.3.30-A4 |
| |
Hi Ingo,
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/
| |