Date: Sun, 31 Mar 2002 09:29:05 -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: <200203311729.g2VHT5h18352@vashon.polstra.com> In-Reply-To: <200203292207.g2TM7Fi67491@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203292207.g2TM7Fi67491@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200203292207.g2TM7Fi67491@apollo.backplane.com>, Matthew
Dillon <dillon@apollo.backplane.com> wrote:
> This won't save you from stalls. Whenever one cpu writes to
> the cache, on IA32, it's write-through to main-memory which
> invalidates all other cpu's caches for that cache line.
No, it's not nearly that bad. See section 9.2 of the IA-32 Intel
Architecture Software Developer's Manual, Volume 3 (24547203.pdf from
developer.intel.com). It describes what happens in a couple of
different scenarios, for example:
Beginning with the P6 family processors, if a processor detects
(through snooping) that another processor is trying to access a
memory location that it has modified in its cache, but has not
yet written back to system memory, the snooping processor will
signal the other processor (by means of the HITM# signal) that
the cache line is held in modified state and will preform an
implicit write-back of the modified data. The implicit write-back
is transferred directly to the initial requesting processor and
snooped by the memory controller to assure that system memory has
been updated. Here, the processor with the valid data may pass
the data to the other proces-sors without actually writing it to
system memory; however, it is the responsibility of the memory
controller to snoop this operation and update memory.
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?200203311729.g2VHT5h18352>