Date: Sun, 31 Mar 2002 11:47:45 -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: <200203311947.g2VJljx89936@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203311834.g2VIYrt89705@apollo.backplane.com> <200203311841.g2VIfcn18637@vashon.polstra.com> <200203311902.g2VJ28i89787@apollo.backplane.com> <200203311914.g2VJEPL18834@vashon.polstra.com>
index | next in thread | previous in thread | raw e-mail
: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.
Ok, I am confusing myself as much as I am confusing the list.
You could very well be right in regards to main memory flushing.
In fact, I think you are right. Sometimes I get on a roll and get way
off track. I was thinking more of the MIPS-3 write queue and confused
it with the pentium. Joy.
My point is that, regardless of the Intel architecture and regardless
of their documentation, it doesn't change the fact that we get big-time
stalls when one cpu writes to a memory location and another cpu reads it,
locked bus cycle or no locked bus cycle. It's that simple.
: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
The linux geniuses were right, actually, but they drew the wrong
conclusions. What they found was a bug in earlier pentium chipsets,
and they found that it was possible to stall the write pipeline
indefinitely and prevent other cpu's from seeing the mutex release
using carefully crafted code.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203311947.g2VJljx89936>