From owner-freebsd-smp Mon Dec 16 18:22:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA25988 for smp-outgoing; Mon, 16 Dec 1996 18:22:04 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA25983 for ; Mon, 16 Dec 1996 18:22:02 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id CAA01102; Tue, 17 Dec 1996 02:20:40 GMT Date: Tue, 17 Dec 1996 11:20:40 +0900 (JST) From: Michael Hancock To: haertel@ichips.intel.com cc: smp@freebsd.org Subject: Re: some questions concerning TLB shootdowns in FreeBSD In-Reply-To: <9612141725.AA57406@pdxcs078.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Dec 1996 haertel@ichips.intel.com wrote: > 1. IPI to everyone sharing these specific PTE's > 2. wait at barrier until everyone arrives > 3. manipulate PTE > 4. release barrier > 5. everyone (including us) flushes TLB's Here's SVR4.2/MP's algorithm for x86 from Unix Internals with terminology translated to what we use: Initiator (Shooter) ------------------- 1. lock pmap acquire global spinlock to prevent other shootdowns 2. send IPI and wait for ack 3. modify ptes 4. increment counter 5. flush own tlb unlock global spinlock unlock pmap Responder --------- 1. receive IPI 2. wait for counter to be incremented 3. flush own tlb In SVR4.2/MP the hat (pmap) has a list of processors that the process could be active on. I don't know if we can make some of the same assumptions for optimizations in FreeBSD, but we can probably find some later. Places to look... 1) Look at all the FreeBSD events that cause tlbs and look for inherent synchronization in the sequence. 2) Look at kernel vs. user tlb invalidations. SVR4.2/MP can guarantee that the kernel won't access an invalid tlb so can it can delay shootdowns and hope that some other event such as a context switch will flush it anyway. 3) Intel specific optimizations. For example it has a level-1 (pointed to by CR3/PDBR) page table containing ptes for level-2 tables. In the multiple pte case it can just invalidate appropriate entries in the level-1 table. The messages here have been leaving me in the dust, I'm sorry if I've said something that's already been discussed. Regards, Mike