From owner-freebsd-hackers Thu Jun 8 11:22:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA22622 for hackers-outgoing; Thu, 8 Jun 1995 11:22:47 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA22605 ; Thu, 8 Jun 1995 11:22:40 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03515; Thu, 8 Jun 95 12:14:20 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506081814.AA03515@cs.weber.edu> Subject: Re: 2.0.5-A: Very disheartening? To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Thu, 8 Jun 95 12:14:20 MDT Cc: uhclem%nemesis@fw.ast.com, jgreco@brasil.moneng.mei.com, hackers@freebsd.org, bugs@freebsd.org In-Reply-To: <199506080331.UAA05773@ref.tfs.com> from "Poul-Henning Kamp" at Jun 7, 95 08:31:14 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > > 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.