Date: Sun, 31 Mar 2002 10:17:14 -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: <200203311817.g2VIHEB18544@vashon.polstra.com> In-Reply-To: <200203311809.g2VI90H89605@apollo.backplane.com> References: <XFMail.20020329155622.jhb@FreeBSD.org> <200203311747.g2VHlII89488@apollo.backplane.com> <200203311752.g2VHqab18408@vashon.polstra.com> <200203311809.g2VI90H89605@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200203311809.g2VI90H89605@apollo.backplane.com>,
Matthew Dillon <dillon@apollo.backplane.com> wrote:
> :
> :Why do you keep saying the Intel caches are write-through? They've
> :been write-back since the Pentium. See table 9-2 in the same document
> :I cited before.
> :
> Maybe I'm using the wrong terminology. What I mean to say is that
> Intel caches, under most conditions, will flush dirty elements in
> their caches to main memory very quickly. i.e. unlike, say, the old
> 68040 cache which leaves dirty cache lines in the cache almost
> indefinitely. The intel caches implement a write ordering constraint
> and a FIFO to deal with dirty data.
>
> Yes, I guess that would be write-back rather then write-through,
> 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
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?200203311817.g2VIHEB18544>