From owner-freebsd-bugs  Tue Jun  6 22:37:11 1995
Return-Path: bugs-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id WAA02063
          for bugs-outgoing; Tue, 6 Jun 1995 22:37:11 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA02057
          for <bugs@freebsd.org>; Tue, 6 Jun 1995 22:37:08 -0700
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id WAA03252; Tue, 6 Jun 1995 22:40:29 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id WAA02429; Tue, 6 Jun 1995 22:37:21 -0700
Message-Id: <199506070537.WAA02429@corbin.Root.COM>
To: William Maddox <maddox@CS.Berkeley.EDU>
cc: Stephen Hocking <sysseh@devetir.qld.gov.au>, bugs@FreeBSD.org
Subject: Re: 2.0.5-A: Very disheartening? 
In-reply-to: Your message of "Tue, 06 Jun 95 22:25:54 PDT."
             <199506070526.WAA29873@redwood.CS.Berkeley.EDU> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Tue, 06 Jun 1995 22:37:19 -0700
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

>>   No. If you don't have cache coherency for things the *CPU* writes to memory,
>> you may as well pack up your marbles and go home. The problem isn't likely
>> caused by any sort of cache problem (even though it is apparantly effected by
>> disabling the cache).
>
>Unfortunately, not all CPU designers agree with you.  It is common
>practice for instruction caches and prefetchers to assume that code is
>immutable once execution begins, and to require special provisions in
>software when this assumption is violated, even if the writing is done
>by the CPU itself!  This is common on machines with split I/D caches,

   That may be, but that's not what is happening here. I agree that
self-modifying code would likely require special provisions for it to
work correctly. The gzip kernel is not modified in place. There is a
decompress program attached at the beginning and the compressed kernel
text/data is then decompressed into its destination memory area.
   What I meant by the above is that things such as IDE disks, NFS, and LKMs
would all break if they required the cache to be flushed every time "data"
was executed. Hell, you wouldn't even be able to do

cc -o hello hello.c; ./hello

   Without it failing since the output ('data') of ld is "cached" and then
executed. This is true both with our current merged VM/buffer cache and with
the old buffer cache scheme.

-DG