Date: Sun, 31 Mar 2002 11:02:08 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Polstra <jdp@polstra.com> Cc: smp@FreeBSD.ORG Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. Message-ID: <200203311902.g2VJ28i89787@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203311809.g2VI90H89605@apollo.backplane.com> <200203311817.g2VIHEB18544@vashon.polstra.com> <200203311834.g2VIYrt89705@apollo.backplane.com> <200203311841.g2VIfcn18637@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203311902.g2VJ28i89787>