From owner-freebsd-smp Tue Feb 1 20:33:31 2000 Delivered-To: freebsd-smp@freebsd.org Received: from web117.yahoomail.com (web117.yahoomail.com [205.180.60.91]) by builder.freebsd.org (Postfix) with SMTP id 482C23DC4 for ; Tue, 1 Feb 2000 20:33:24 -0800 (PST) Received: (qmail 8846 invoked by uid 60001); 2 Feb 2000 04:28:29 -0000 Message-ID: <20000202042829.8845.qmail@web117.yahoomail.com> Received: from [203.127.104.35] by web117.yahoomail.com; Tue, 01 Feb 2000 20:28:29 PST Date: Tue, 1 Feb 2000 20:28:29 -0800 (PST) From: Chee Wei Ng Subject: Re: MPrellock_edx To: freebsd-smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --- Matthew Dillon 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 > > 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