Date: Sun, 31 Mar 2002 10:34:53 -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: <200203311834.g2VIYrt89705@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203311747.g2VHlII89488@apollo.backplane.com> <200203311752.g2VHqab18408@vashon.polstra.com> <200203311809.g2VI90H89605@apollo.backplane.com> <200203311817.g2VIHEB18544@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> But not delayed-write.
:
:It is both write-back and delayed-write. Section 9.10 ("Store
:Buffer") describes it:
:
: IA-32 processors temporarily store each write (store) to memory in
: a store buffer. The store buffer improves processor performance by
: allowing the processor to continue executing instructions without
: having to wait until a write to memory and/or to a cache is
: complete. It also allows writes to be delayed for more efficient
: use of memory-access bus cycles.
:
:Table 9-1 states that the store buffer has 24 entries on the Pentium 4,
:and 12 entries on the P6 family.
:
:John
:--
: John Polstra
: John D. Polstra & Co., Inc. Seattle, Washington USA
: "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
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.
This means that a write will be pushed out to main memory in fairly
short order. The only way to prevent this from occuring is to saturate
the memory bus with cache-missed reads. There is no confusion here, the
linux folks did a massive amount of testing of this when they were
trying to decide whether to force a flush after releasing a mutex or
whether to allow the cpu to flush it out in the background. Tests
showed that the cpu would normally flush the data out within a
microsecond or two unless code was carefully crafted to saturate the
memory bus with reads.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200203311834.g2VIYrt89705>