Date: Tue, 06 Jun 1995 22:37:19 -0700 From: David Greenman <davidg@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? Message-ID: <199506070537.WAA02429@corbin.Root.COM> In-Reply-To: Your message of "Tue, 06 Jun 95 22:25:54 PDT." <199506070526.WAA29873@redwood.CS.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506070537.WAA02429>