--79888902-1654562748-943983364=:5368
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
--79888902-1654562748-943983364=:5368
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="spinlock-2.3.30-A4"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9911301836040.5368@chiara.csoma.elte.hu>
Content-Description:
Content-Disposition: attachment; filename="spinlock-2.3.30-A4"
LS0tIGxpbnV4L2luY2x1ZGUvYXNtLWkzODYvc3BpbmxvY2suaC5vcmlnCVR1
ZSBOb3YgMzAgMDY6NDk6MDkgMTk5OQ0KKysrIGxpbnV4L2luY2x1ZGUvYXNt
LWkzODYvc3BpbmxvY2suaAlUdWUgTm92IDMwIDA4OjU5OjU0IDE5OTkNCkBA
IC0zMyw3ICszMyw3IEBADQogI2RlZmluZSBTUElOTE9DS19NQUdJQ19JTklU
CS8qICovDQogI2VuZGlmDQogDQotI2RlZmluZSBTUElOX0xPQ0tfVU5MT0NL
RUQgKHNwaW5sb2NrX3QpIHsgMCBTUElOTE9DS19NQUdJQ19JTklUIH0NCisj
ZGVmaW5lIFNQSU5fTE9DS19VTkxPQ0tFRCAoc3BpbmxvY2tfdCkgeyAxIFNQ
SU5MT0NLX01BR0lDX0lOSVQgfQ0KIA0KICNkZWZpbmUgc3Bpbl9sb2NrX2lu
aXQoeCkJZG8geyAqKHgpID0gU1BJTl9MT0NLX1VOTE9DS0VEOyB9IHdoaWxl
KDApDQogLyoNCkBAIC00MywyMSArNDMsMjQgQEANCiAgKiBXZSBtYWtlIG5v
IGZhaXJuZXNzIGFzc3VtcHRpb25zLiBUaGV5IGhhdmUgYSBjb3N0Lg0KICAq
Lw0KIA0KLSNkZWZpbmUgc3Bpbl91bmxvY2tfd2FpdCh4KQlkbyB7IGJhcnJp
ZXIoKTsgfSB3aGlsZSgoKHZvbGF0aWxlIHNwaW5sb2NrX3QgKikoeCkpLT5s
b2NrKQ0KKyNkZWZpbmUgc3Bpbl91bmxvY2tfd2FpdCh4KQlkbyB7IGJhcnJp
ZXIoKTsgfSB3aGlsZSgoKHZvbGF0aWxlIHNwaW5sb2NrX3QgKikoeCkpLT5s
b2NrICE9IDEpDQogDQorLyoNCisgKiBUaGlzIHNwaW5sb2NrIHZhcmlhbnQg
d29ya3MgZm9yIHVwIHRvIDI1NSBDUFVzLg0KKyAqLw0KICNkZWZpbmUgc3Bp
bl9sb2NrX3N0cmluZyBcDQogCSJcbjE6XHQiIFwNCi0JImxvY2sgOyBidHNs
ICQwLCUwXG5cdCIgXA0KLQkiamMgMmZcbiIgXA0KKwkibG9jayA7IGRlY2Ig
JTBcblx0IiBcDQorCSJqbnogMmZcbiIgXA0KIAkiLnNlY3Rpb24gLnRleHQu
bG9jayxcImF4XCJcbiIgXA0KIAkiMjpcdCIgXA0KLQkidGVzdGIgJDEsJTBc
blx0IiBcDQorCSJjbXBiICQxLCUwXG5cdCIgXA0KIAkiam5lIDJiXG5cdCIg
XA0KIAkiam1wIDFiXG4iIFwNCiAJIi5wcmV2aW91cyINCiANCiAjZGVmaW5l
IHNwaW5fdW5sb2NrX3N0cmluZyBcDQotCSJtb3ZiICQwLCUwIg0KKwkibW92
YiAkMSwlMCINCiANCiBleHRlcm4gaW5saW5lIHZvaWQgc3Bpbl9sb2NrKHNw
aW5sb2NrX3QgKmxvY2spDQogew0KQEAgLTg1LDcgKzg4LDcgQEANCiAJCToi
PW0iIChfX2R1bW15X2xvY2sobG9jaykpKTsNCiB9DQogDQotI2RlZmluZSBz
cGluX3RyeWxvY2sobG9jaykgKCF0ZXN0X2FuZF9zZXRfYml0KDAsKGxvY2sp
KSkNCisjZGVmaW5lIHNwaW5fdHJ5bG9jayhsb2NrKSAoIWF0b21pY19kZWNf
YW5kX3Rlc3QoKGF0b21pY190KikobG9jaykpKQ0KIA0KIC8qDQogICogUmVh
ZC13cml0ZSBzcGlubG9ja3MsIGFsbG93aW5nIG11bHRpcGxlIHJlYWRlcnMN
Cg==
--79888902-1654562748-943983364=:5368--
-
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/