From owner-freebsd-hardware  Sun Jun  1 04:26:42 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id EAA18757
          for hardware-outgoing; Sun, 1 Jun 1997 04:26:42 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA18744;
          Sun, 1 Jun 1997 04:26:32 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA19986; Sun, 1 Jun 1997 21:25:02 +1000
Date: Sun, 1 Jun 1997 21:25:02 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199706011125.VAA19986@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, roberto@keltia.freenix.fr
Subject: Re: Intel Pentium II released
Cc: hardware@FreeBSD.ORG, kato@FreeBSD.ORG
Sender: owner-hardware@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> * A sysctl-controlled variable would be nice although I don"t see why anyone
> * would want to run without this feature :-)
>
>Actually, write allocate may not help or even hurt if you are copying
>large amount of data.  If it is implemented the straightforward way,
>i.e., to read the rest of the bytes in the line when a write to a
>currently uncached memory ("read-before-writes"), those reads will be
>simply wasted as the rest of the line is going to be quickly
>overwritten by writes from the CPU.  For this reason, we might even
>want to disable write caching entirely during a large memory copy (no
>need to keep them in cache if they are not going to be read again soon 
>enough).

It does seem to be implemented in a straightforward way on P6/Natoma
systems.  This results in a about 2 times slowdown for the
`dd if=/dev/zero of=/dev/null bs=1m' test and a 3/2 times slowdown for
large bcopies.

I tried setting the per-page cache disable bits in pmap_zero_page() and
pmap_zero_page().  I couldn't see any effect on a P5 system.  This is
not surprising, since there is no write allocation on P5's.  Note that
pmap_zero_page() and pmap_copy_page() invalidate the caching for the
pages after accessing them, so any write caching is harmful - cached
data on other pages is discarded to make room, then the results of the
write are discarded.  Read caching is probably harmful except in the
"i586-optimized" case which depends on it.

>Well, even if you know the assembler syntax, you need an assembler
>that understands it don't you. :)

No :-).  See wrmsr().

Bruce