Date: Tue, 06 Jun 1995 22:25:54 -0700 From: William Maddox <maddox@CS.Berkeley.EDU> To: davidg@Root.COM Cc: Stephen Hocking <sysseh@devetir.qld.gov.au>, bugs@FreeBSD.org, maddox@redwood.CS.Berkeley.EDU Subject: Re: 2.0.5-A: Very disheartening? Message-ID: <199506070526.WAA29873@redwood.CS.Berkeley.EDU> In-Reply-To: Your message of "Tue, 06 Jun 1995 11:47:01 PDT." <199506061848.LAA00541@corbin.Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Might this not have something to do with unzipping something > >executable into memory and then failing to invalidate the cache entries for > >the memory you've just unzipped into? It sounds like a failure mode that > >you'd see with machines that have split I/D caches. I know it's easy to yell > >suggestions from the sidelines, but wouldn't it be a good idea to invalidate > >the cache after the image has been unzipped into memory? > > 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, but also affects machines with a simple instruction prefetch buffer in the case of code that modifies an instruction a short distance ahead of the current PC. Usually, code is only loaded by the OS, so most applications don't have to worry about this. There are a few screwball things applications do, such as dynamic linking and on-the-fly compilation, that run afoul of this, but the vendors don't seem to consider these important enought to support in a clean and portable way. I have in front of me the documentation for dynamic loading of executable files on the HP 9000 series machines using the old-fashioned 'ld -A' mechanism. The executable object file is loaded into the data segment via an ordinary file read operation. It is clearly stated that the text must be flushed from the data cache prior to beginning execution. On these machines, there are actually two different, incompatible ways in which this is done: On the Series 300/400 machines, the call 'cachectl(CC_FLUSH, 0, 0)' does the trick. On the Series 700/800, a page-long segment of semi-magical assembly code, loaded with wired-in assumptions about the cache architecture, is required. All of this is documented by HP. There was an extensive discussion of on-the-fly compilation on the net a while back, and I recall that the PA-RISC is by no means exceptional. I can't speak authoritatively for the Pentium, though, as I don't have the manuals. > > -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506070526.WAA29873>