Date: Sun, 31 Mar 2002 11:14:25 -0800 (PST) From: John Polstra <jdp@polstra.com> To: smp@freebsd.org Cc: dillon@apollo.backplane.com Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. Message-ID: <200203311914.g2VJEPL18834@vashon.polstra.com> In-Reply-To: <200203311902.g2VJ28i89787@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203311834.g2VIYrt89705@apollo.backplane.com> <200203311841.g2VIfcn18637@vashon.polstra.com> <200203311902.g2VJ28i89787@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200203311902.g2VJ28i89787@apollo.backplane.com>, Matthew Dillon <dillon@apollo.backplane.com> wrote: > > :> Now we are quibbling over terminology. Intel caches have a write FIFO. > :> They are not a full-blown delayed-write caches. There is a BIG > :> difference. That is, you can't have an arbitrary amount of dirty data > :> sitting in an intel cache. > : > :There is nothing in the Intel documentation which would support that > :statement. The cache is write-back. Nowhere does the documentation > :say anything about dirty lines being flushed to memory except when > :required by the cache control protocol (which is pretty standard). > : > :> This means that a write will be pushed out to main memory in fairly > :> short order. > : > :No, I don't think so. There is no evidence of that in the Intel > :docs. > : > I can't argue against faith, I suppose, You are not arguing against faith, you are arguing against the documentation. I provided references for the claims I made, but I haven't seen any references coming back the other way. > but you shouldn't be so quick > to throw away the thousands of emails on the Linux and FreeBSD lists > and at least a dozen people who have have tested this stuff on real > live machines. The linux folks did some pretty severe testing, > especially testing of non-flushed write-latencies in MP systems. I > did some testing of this myself when I redid the low level MP locking > code. All of it is available on the lists if you look. It doesn't > magically go away because the documentation says so (or doesn't say so > in this case). > > In otherwords, what I'm talking about here is the reality of the hardware, > found through testing. When John brought up using a non-locked bus cycle, > for example, I tested the case and found that it doesn't prevent stalls. > > If you want to assert that I am incorrect then I strongly recommend that > you back those assertions up with your own tests showing otherwise. I am not disputing your tests. I am disputing the conclusions you drew from them. > Also, I'm not sure why you seem to read so much into the Intel > documentation. Intel documentation is notoriously incomplete in many > respects and just plain wrong in others. For example, the linux folks > have shown definitively that if MP systems do dirty-pending-write snooping > at all, it doesn't help latencies in the least. I think that in Intel's > entire documentation set they only talk about MP write ordering in one > or two places. I don't remember where, but I do remember the linux > folks having to dig fairly deeply to find it. They finally located > an Intel engineer and asking him for the final word on the matter, > in fact. Bad example. I'm quite familiar with that thread. You are right that they finally consulted an Intel engineer who set them straight. The part you apparently missed is that the Intel engineer confirmed what the Intel documentation already stated. In other words, what all the Linux geniuses argued with great confidence in their mailing lists turned out to be utterly wrong. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa 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?200203311914.g2VJEPL18834>