From owner-freebsd-smp Sun Mar 31 10:35: 3 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 973A137B417 for ; Sun, 31 Mar 2002 10:34:55 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2VIYrt89705; Sun, 31 Mar 2002 10:34:53 -0800 (PST) (envelope-from dillon) Date: Sun, 31 Mar 2002 10:34:53 -0800 (PST) From: Matthew Dillon Message-Id: <200203311834.g2VIYrt89705@apollo.backplane.com> To: John Polstra Cc: smp@FreeBSD.ORG Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. References: <200203311747.g2VHlII89488@apollo.backplane.com> <200203311752.g2VHqab18408@vashon.polstra.com> <200203311809.g2VI90H89605@apollo.backplane.com> <200203311817.g2VIHEB18544@vashon.polstra.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message