From owner-freebsd-smp Sun Mar 31 11: 2:26 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5865D37B417 for ; Sun, 31 Mar 2002 11:02:21 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2VJ28i89787; Sun, 31 Mar 2002 11:02:08 -0800 (PST) (envelope-from dillon) Date: Sun, 31 Mar 2002 11:02:08 -0800 (PST) From: Matthew Dillon Message-Id: <200203311902.g2VJ28i89787@apollo.backplane.com> To: John Polstra Cc: smp@FreeBSD.ORG Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. References: <200203311809.g2VI90H89605@apollo.backplane.com> <200203311817.g2VIHEB18544@vashon.polstra.com> <200203311834.g2VIYrt89705@apollo.backplane.com> <200203311841.g2VIfcn18637@vashon.polstra.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :> 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. : :John :-- : John Polstra I can't argue against faith, I suppose, 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. 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message