From owner-freebsd-smp Mon Dec 23 23:19:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id XAA12493 for smp-outgoing; Mon, 23 Dec 1996 23:19:41 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA12484 for ; Mon, 23 Dec 1996 23:19:28 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id PAA00923; Tue, 24 Dec 1996 15:17:38 +0800 (WST) Message-Id: <199612240717.PAA00923@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: dg@root.com cc: Erich Boleyn , smp@freebsd.org, haertel@ichips.intel.com, wscott@ichips.intel.com Subject: Re: I think we have the culprit!! (was -> Re: Eureka (maybe...) (was -> Re: P6 problem idea ) ) In-reply-to: Your message of "Mon, 23 Dec 1996 22:52:09 PST." <199612240652.WAA27742@root.com> Date: Tue, 24 Dec 1996 15:17:37 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Greenman wrote: > >If so, we need to refine the implementation of TLB shootdowns more so that > >we can initiate a per-page flush as well as a global flush.. This will > >require syncronisation, so if you can send your code you can save some > >reinvention.. :-) > > Uh, no, I don't think that is the right solution. The single-page > invalidates are going to be too expensive in the SMP case. I think a > better solution would be to simply only set the PG_G flag for static > mappings (kernel text, data, and bss), and NOT set it for other kernel > mappings if SMP is true. This is a trivial change to pmap.c. What I had in mind was simply storing up to the two addresses. When the IPI handler on the slave CPU fires, it checks the first address. If it's zero, it does a global invalidate and returns. If it's set it does an invlpg on the address. If the second one is set, it does an invlpg on that one too. The cost of doing this relative to the cost of the IPI in the first place should be pretty small since it's just a few extra instructions. How expensive are global unnecessary TLB refills? Since only one cpu can ever be sending a TLB flush at any given time (only one in the kernel proper), we have implicit locking for free. We need to wait for the target cpu's to process the invalidates anyway before we start using "stolen" pages etc so with that feature present we should not have to worry about protecting the two address pointers from reuse before all cpu's have finished using them. Cheers, -Peter