From owner-freebsd-current Fri Jul 12 2:29:47 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24DAF37B400 for ; Fri, 12 Jul 2002 02:29:43 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C49143E58 for ; Fri, 12 Jul 2002 02:29:42 -0700 (PDT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 185462A7D6 for ; Fri, 12 Jul 2002 02:29:42 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id B56FA4C220 for ; Fri, 12 Jul 2002 02:29:41 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id B03793811 for ; Fri, 12 Jul 2002 02:29:41 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: current@freebsd.org Subject: HEADS UP, beware of pmap changes. Date: Fri, 12 Jul 2002 02:29:41 -0700 From: Peter Wemm Message-Id: <20020712092941.B03793811@overcee.wemm.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is mostly a FYI because I do not expect major problems this time. I have been extensively testing it in a handful of configurations. I expect this to have bigger positive effects than are apparent from the stats I quoted in the commit message from 'make world' for SMP systems, especially for pentium/pentiumpro/2/3 systems. Pentium4 Xeon I am not sure about.. it has a fast APIC subsystem, but the penalties for taking traps etc are quite different. There are a few more changes that I want to do over the next few days that build on top of this - I backed a couple of things out of this change that I thought were working but I didn't want to risk them yet. If I've broken something new, please yell. I must confess that I have not tried to use vm86 doscmd or anything perverse like that. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 ------- Forwarded Message Date: Fri, 12 Jul 2002 00:56:11 -0700 From: Peter Wemm To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/conf options.i386 options.pc98 src/sys/i386/i386 b ios.c db_interface.c locore.s mp_machdep.c mpapic.c pmap.c support.s vm86.c src/sys/i386/include cpufunc.h pmap.h smp.h src/sys/i386/isa a pic_vector.s intr_machdep.h ... peter 2002/07/12 00:56:11 PDT Modified files: sys/conf options.i386 options.pc98 sys/i386/i386 bios.c db_interface.c locore.s mp_machdep.c mpapic.c pmap.c support.s vm86.c sys/i386/include cpufunc.h pmap.h smp.h sys/i386/isa apic_vector.s intr_machdep.h sys/kern subr_witness.c Log: Revive backed out pmap related changes from Feb 2002. The highlights are: - It actually works this time, honest! - Fine grained TLB shootdowns for SMP on i386. IPI's are very expensive, so try and optimize things where possible. - Introduce ranged shootdowns that can be done as a single IPI. - PG_G support for i386 - Specific-cpu targeted shootdowns. For example, there is no sense in globally purging the TLB cache for where we are stealing a page from the local unshared process on the local cpu. Use pm_active to track this. - Add some instrumentation for the tlb shootdown code. - Rip out SMP code from - Try and fix some very bogus PG_G and PG_PS interactions that were bad enough to cause vm86 bios calls to break. vm86 depended on our existing bugs and this was the cause of the VESA panics last time. - Fix the silly one-line error that caused the 'panic: bad pte' last time. - Fix a couple of other silly one-line errors that should have caused more pain than they did. Some more work is needed: - pmap_{zero,copy}_page[_idle]. These can be done without IPI's if we have a hook in cpu_switch. - The IPI handlers need some cleanup. I have a bogus %ds load that can be avoided. - APTD handling is rather bogus and appears to be a large source of global TLB IPI shootdowns for no really good reason. I see speedups of between 1.5% and ~4% on buildworlds in a while 1 loop. I expect to see a bigger difference when there is significant pageout activity or the system otherwise has memory shortages. I have backed out a few optimizations that I had been using over the last few days in order to be a little more conservative. I'll revisit these again over the next few days as the dust settles. New option: DISABLE_PG_G - In case I missed something. Revision Changes Path 1.172 +2 -1 src/sys/conf/options.i386 1.147 +2 -1 src/sys/conf/options.pc98 1.54 +8 -7 src/sys/i386/i386/bios.c 1.66 +2 -2 src/sys/i386/i386/db_interface.c 1.158 +3 -21 src/sys/i386/i386/locore.s 1.188 +231 -23 src/sys/i386/i386/mp_machdep.c 1.59 +0 -3 src/sys/i386/i386/mpapic.c 1.337 +261 -249 src/sys/i386/i386/pmap.c 1.91 +0 -36 src/sys/i386/i386/support.s 1.47 +2 -0 src/sys/i386/i386/vm86.c 1.126 +93 -75 src/sys/i386/include/cpufunc.h 1.80 +5 -4 src/sys/i386/include/pmap.h 1.71 +9 -1 src/sys/i386/include/smp.h 1.84 +82 -5 src/sys/i386/isa/apic_vector.s 1.42 +13 -7 src/sys/i386/isa/intr_machdep.h 1.121 +3 -0 src/sys/kern/subr_witness.c ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message