Date: Tue, 1 Feb 2000 20:28:29 -0800 (PST) From: Chee Wei Ng <scip7050@yahoo.com> To: freebsd-smp@freebsd.org Subject: Re: MPrellock_edx Message-ID: <20000202042829.8845.qmail@web117.yahoomail.com>
next in thread | raw e-mail | index | archive | help
--- Matthew Dillon <dillon@apollo.backplane.com> wrote: > I discussed this issue with Linus after someone from the linux kernel > group brought it up. Basically we have adopted the same thing that linux > uses. > > Under Intel, the following is true: > > * Writes are buffered but are committed to memory in the same > order they were issued. Thus write<->write conflicts are not > an issue. > > * Speculative reads may occur, but they occur from main memory > into the L1 cache and thus still adhere to L1 cache protocols. > Thus speculative reads are not an issue. > > * The cpu may reorder non-conflicting reads. A non-conflicting > read may be reordered from *before* a write to *after* a write, > or from *after* a write to *before* a write. > > This is an issue. This is the ONLY issue with intel hardware. > > The purpose of the locked instruction is to prevent any possibility > of reads being reordered from to after the MP lock is released. > So, the issue is non-conflicting re-ordered read. But, I still don't see why this issue has impact on the CS. Further illustration with an example will be grateful. The following solution will be cleared if the above issue is really an issue. > There has been a huge amount of misinformation on the issue. I looked > at both the linux kernel and the Freebsd mail archives and 90% of > the messages posted entertaining one opinion or another were just plain > wrong (and Linus agrees with me). We don't know whether the read > reordering issue is real or not. We do know that none of the other > issues brought up were real. > > We aren't taking any chances with the read re-ordering issue and so > we have a locked instruction. > > The reason we use 0(%esp) for the locked memory address is because > there is nearly a 100% chance that that address is already in our > processor's L1 cache *AND* that we have (via the hardware cache > protocol) exclusive ownership of the address, thus minimizing the cost > of running the instruction. > > The reason we do not use a locked instruction to actually release the > MP lock is because: > > (A) we don't have to, writes are ordered and we do not care if > reads are reordered to occur before the write releasing the > lock is committed. > > (B) because if there is another processor trying for the lock we > may not have exclusive ownership of the lock address in our L1 > cache (the other cpu might), costing us a huge stall due to > the way the hardware cache coherency protocol work. > > -Matt > Matthew Dillon > <dillon@backplane.com> > NgCW __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000202042829.8845.qmail>