Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Apr 2003 13:42:21 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 29365 for review
Message-ID:  <20030421204221.GA830@athlon.pn.xcllnt.net>
In-Reply-To: <200304212028.h3LKSg2v082838@repoman.freebsd.org>
References:  <200304212028.h3LKSg2v082838@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 21, 2003 at 01:28:42PM -0700, Marcel Moolenaar wrote:
> http://perforce.freebsd.org/chv.cgi?CH=29365
> 
> Change 29365 by marcel@marcel_nfs on 2003/04/21 13:27:48
> 
> 	Use a non-trapping implementation for pmap_kextract.
> 	This has been deliberately made non-inlined for now
> 	to help profiling, debugging and whatsnot. Be extra
> 	careful (probably over-correctingly so :-) with the
> 	address passed to us, because it may be an address
> 	given to use from user space.
> 	
> 	Note that an inlined or partially inlined version
> 	should be used eventually. It appears that UMA is
> 	a regular user of pmap_kextract and rudimentary
> 	testing showed that it's mostly for direct mapped
> 	KVAs. Doing the test for direct mapped KVAs inlined
> 	will probably be worth it.
> 	
> 	Valuable insights by: jake

JFYI:

I noticed a reduction in the number of Nested TLB faults, so it
appears that not depending on the cpu's TLB for pmap_kextract has
a side-effect of not polluting the translation cache.

I also have a nagging suspicion that it may have been the cause
of not being able to run a MP kernel on the HP boxes in the
FreeBSD cluster, even though SMP works (roughly) on the BigSur.
On the HP boxes the BSP and AP get entangled in a life-lock
where the AP holds sched_lock, while waiting for Giant that the
BSP holds. The BSP is likely in hardclock and the AP is typically
in UMA (I may have got the details slightly wrong). Since the
AP has mostly a clean translation cache it's probably faulting
a lot and may possibly end up in vm_fault. Again, this is just a
nagging suspicion...

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030421204221.GA830>