From owner-cvs-all Tue Feb 26 10:13:13 2002 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1B28C37B41C; Tue, 26 Feb 2002 10:12:34 -0800 (PST) Received: (from dillon@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1QICYM65173; Tue, 26 Feb 2002 10:12:34 -0800 (PST) (envelope-from dillon) Date: Tue, 26 Feb 2002 10:12:34 -0800 (PST) From: Message-Id: <200202261812.g1QICYM65173@freefall.freebsd.org> To: Peter Wemm Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options.i386 options.pc98 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I had to make a minor change to this file to fix a conflict created by my critical_enter()/exit() code. Basically, my critical_enter()/exit() code already fixes the IPI deadlock problem by leaving interrupts enabled, so your specific cpu_critical_exit() call can be conditionalized for i386. BTW, I have to strongly disagree with the hack you had in there, even though I understand why you did it. critical_enter(), critical_exit(), cpu_critical_enter(), and cpu_critical_exit() are twisted together in a very bad way in fork_exit(), ast(), and now in i386/i386/pmap.c (but at least i386/i386/pmap.c is MD code). -Matt : Log: : Work-in-progress commit syncing up pmap cleanups that I have been working : on for a while: : - fine grained TLB shootdown for SMP on i386 : - ranged TLB shootdowns.. eg: specify a range of pages to shoot down with : a single IPI, since the IPI is very expensive. Adjust some callers : that used to trigger this inside tight loops to do a ranged shootdown : at the end instead. : - PG_G support for SMP on i386 (options ENABLE_PG_G) : - defer PG_G activation till after we decide what we are going to do with : PSE and the 4MB pages at the start of the kernel. This should solve : some rumored strangeness about stale PG_G entries getting stuck : underneath the 4MB pages. : - add some instrumentation for the fine TLB shootdown : - convert some asm instruction wrappers from functions to inlines. gcc : seems to do a fair bit better with this. : - [temporarily!] pessimize the tlb shootdown IPI handlers. I will fix : this again shortly. : : This has been working fairly well for me for a while, but I have tweaked : it again prior to commit since my last major testing round. The only : outstanding problem that I know of is PG_G related, which is why there : is an option for it (not on by default for SMP). I have seen a world : speedups by a few percent (as much as 4 or 5% in one case) but I have : *not* accurately measured this - I am a bit sceptical of these numbers. : : Revision Changes Path : 1.168 +1 -0 src/sys/conf/options.i386 : 1.142 +1 -0 src/sys/conf/options.pc98 : 1.155 +2 -21 src/sys/i386/i386/locore.s : 1.175 +193 -18 src/sys/i386/i386/mp_machdep.c : 1.53 +0 -3 src/sys/i386/i386/mpapic.c : 1.308 +174 -198 src/sys/i386/i386/pmap.c : 1.87 +0 -36 src/sys/i386/i386/support.s : 1.109 +169 -75 src/sys/i386/include/cpufunc.h : 1.75 +0 -2 src/sys/i386/include/pmap.h : 1.67 +2 -1 src/sys/i386/include/smp.h : 1.41 +1 -8 src/sys/i386/include/smptests.h : 1.76 +83 -11 src/sys/i386/isa/apic_vector.s : 1.66 +0 -8 src/sys/i386/isa/intr_machdep.c : 1.34 +13 -7 src/sys/i386/isa/intr_machdep.h : 1.99 +3 -0 src/sys/kern/subr_witness.c : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message