From owner-freebsd-smp Tue Nov 23 9: 3:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 79FB514C4F for ; Tue, 23 Nov 1999 09:03:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA09896; Tue, 23 Nov 1999 09:03:00 -0800 (PST) (envelope-from dillon) Date: Tue, 23 Nov 1999 09:03:00 -0800 (PST) From: Matthew Dillon Message-Id: <199911231703.JAA09896@apollo.backplane.com> To: Peter Wemm Cc: Tommy Hallgren , freebsd-smp@FreeBSD.ORG Subject: Re: Matt's new unlock optimiazation References: <19991123140128.3A7D41C6D@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> The entire thread is here: :> http://boudicca.tux.org/hypermail/linux-kernel/this-week/subject.html#start :> :> The subject is: spin_unlock optimization(i386) : :A bit worrying, to say the least, especially coming from Linus (even moreso :in light of his work at transmeta and what they're doing with/to Intel cpu's). : :Cheers, :-Peter hmm. I was under the impression that the Pentium serialized writes by reserving locations through their caches. But knowing Intel, Linus is probably right. Sometimes I wish I could just take a gun to the Pentium. But this isn't a big deal, we should simply be able to do a locked write into the per-cpu area to synchronize just before we release the lock. This is still going to be a whole lot more efficient then trying to lock a write to the shared lock, because we will almost certainly already own that memory location. I'll run some tests and commit a solution Nobody commit anything. No matter what, we still get the benefit of the recursion lock optimization which is actually the more important one. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message