Date: Thu, 8 Jun 95 12:14:20 MDT From: terry@cs.weber.edu (Terry Lambert) To: phk@ref.tfs.com (Poul-Henning Kamp) Cc: uhclem%nemesis@fw.ast.com, jgreco@brasil.moneng.mei.com, hackers@freebsd.org, bugs@freebsd.org Subject: Re: 2.0.5-A: Very disheartening? Message-ID: <9506081814.AA03515@cs.weber.edu> In-Reply-To: <199506080331.UAA05773@ref.tfs.com> from "Poul-Henning Kamp" at Jun 7, 95 08:31:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Try it to humor me? Have anything else to try that you are more confident > > Terry, you may be unfamiliar with x86 terminology. All I tried to say > was that the transfer to the uncompressed code was a "far jump" which > until now has always flushed the prefetch. You only need to bother > with the prefetch queue if you modify instructions in you close > neighborhood. According to a posting a while back in the linux developer news group, there was an issue with jumps *not* flushing the prefetch queue that was throwing off a CPU timing test of some kind. I forget the details. It was not clear that the "far jump" in fact covered "a large distance" or was simply being used as a prefetch flushing mechanism. What I was suggesting was an alternate flushing mechanism (filling the thing up with NOPs). I guess a question I have is how the distinction is made between I and D in the code leading up to the kernel being executed. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506081814.AA03515>