Date: Tue, 26 Feb 2002 10:12:34 -0800 (PST) From: <dillon@FreeBSD.org> To: Peter Wemm <peter@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf options.i386 options.pc98 Message-ID: <200202261812.g1QICYM65173@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202261812.g1QICYM65173>