atom feed16 messages in org.freebsd.freebsd-smpRe: Matt's new unlock optimiazation
FromSent OnAttachments
Tommy HallgrenNov 23, 1999 5:39 am 
Peter WemmNov 23, 1999 6:01 am 
Poul-Henning KampNov 23, 1999 6:09 am 
Matthew DillonNov 23, 1999 9:02 am 
Matthew DillonNov 23, 1999 9:51 am 
Matthew DillonNov 23, 1999 10:18 am 
Matthew DillonNov 23, 1999 10:23 am 
Matthew DillonNov 23, 1999 10:23 am 
Alan CoxNov 23, 1999 10:38 am 
Matthew DillonNov 23, 1999 11:00 am 
Matthew DillonNov 23, 1999 11:41 am 
Matthew DillonNov 23, 1999 11:50 am 
Alfred PerlsteinNov 23, 1999 12:01 pm 
Alan CoxNov 23, 1999 12:22 pm 
Alan CoxNov 23, 1999 12:52 pm 
Alfred PerlsteinNov 23, 1999 1:09 pm 
Subject:Re: Matt's new unlock optimiazation
From:Matthew Dillon (dil@apollo.backplane.com)
Date:Nov 23, 1999 9:02:38 am
List:org.freebsd.freebsd-smp

:> 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.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message