Date: Tue, 1 Feb 2000 20:08:33 -0800 (PST) From: Chee Wei Ng <scip7050@yahoo.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-smp@freebsd.org Subject: Re: MPrellock_edx Message-ID: <20000202040833.4103.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. OK! So the issue here is non-conflict read re-ordering. But I still don't see why there is an impact on corrupting the CS. (Maybe I am too stupid). Further illustration with an example will be grateful. If the above issue is as it is, I understand why you used the below method to resolve the above 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> > > Thanks. Rgds, 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?20000202040833.4103.qmail>