From owner-freebsd-smp Sun Dec 15 16:59:32 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA24420 for smp-outgoing; Sun, 15 Dec 1996 16:59:32 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA24404; Sun, 15 Dec 1996 16:59:24 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id TAA05793; Sun, 15 Dec 1996 19:58:05 -0500 (EST) From: "John S. Dyson" Message-Id: <199612160058.TAA05793@dyson.iquest.net> Subject: Re: some questions concerning TLB shootdowns in FreeBSD To: terry@lambert.org (Terry Lambert) Date: Sun, 15 Dec 1996 19:58:05 -0500 (EST) Cc: toor@dyson.iquest.net, phk@critter.tfs.com, peter@spinner.dialix.com, dyson@freebsd.org, smp@freebsd.org, haertel@ichips.intel.com In-Reply-To: <199612152032.NAA23823@phaeton.artisoft.com> from "Terry Lambert" at Dec 15, 96 01:32:03 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry, I am NOT discounting your suggestions -- but I am bringing up challenges associated with your suggestions. > > Some potential optimizations: > > 1) This only applys to written pages not marked copy-on-write; > read-only pages and pages that will be copied on write (like > those in your note about "address spaces are already shared") > You still need to be able to globally invalidate pages that are mapped read-only. (e.g. paging out (where things can happen anytime, or object reclaimation -- that of course doesn't happen unless an object is done with.)) > 2) Flushing can be "lazy" in most cases. That is, the page could > be marked invalid for a particular CPU, and only flushed if > that CPU needs to use it. For a generic first time implementation, > a single unsigned long with CPU invalidity bits could be used > (first time because it places a 32 processor limit, which I > feel is an unacceptable limitation -- I want to run on Connection > Machines some day) as an addition to the page attributes. For > the most part, it is important to realize that this is a > negative validity indicator. This dictates who has to do > the work: the CPU that wants to access the page. The higher > the process CPU affinity, the less this will happen. > There is no special indication of a TLB entry being updated in a processor from the page tables. So, once there is a page table entry created, we have no indication when the processor grabs it (I seem to remember that there are ways for coercing P6's and perhaps P5's into doing it though.) The only way that I would try to do it is to get information from Intel saying that the method is "blessed." It could break things for other (non-Intel) CPU's though. John