Date: Sun, 1 Jun 1997 21:25:02 +1000 From: Bruce Evans <bde@zeta.org.au> To: asami@cs.berkeley.edu, roberto@keltia.freenix.fr Cc: hardware@FreeBSD.ORG, kato@FreeBSD.ORG Subject: Re: Intel Pentium II released Message-ID: <199706011125.VAA19986@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706011125.VAA19986>