Forward: Re: Need Comdex builds...

[Jun Ebihara <jun@soum.co.jp>]

Simonさんのこのパッチをためしてみています。

---

• Subject: Re: Need Comdex builds...
• From: Simon Burge <simonb@netbsd.org>
• To: Takao Shinohara <shin@sm.sony.co.jp>
• Date: Sun, 07 Nov 1999 13:12:08 +1100
• Message-Id: <199911070212.NAA03608@balrog.supp.cpr.itg.telecom.com.au>
• In-Reply-To: Your message of "Sun, 07 Nov 99 08:13:18 +0900 "<9911062313.AA07607@lachesis.sm.sony.co.jp>
• Cc: "Charles M. Hannum" <root@ihack.net>, netbsd-developers@netbsd.org
• Delivered-To: jun@netbsd.org
• Delivered-To: netbsd-developers@netbsd.org

Takao Shinohara wrote:

> "Charles M. Hannum" <root@ihack.net> writes:
>
> > possibly hpcmips?  (Anyone awake in Japan?)
> 
> I have just started build/release process for hpcmips. But it takes
> about 48 hours to complete. I'm afraid of being late for deadline.

Could this slowness be related to the anon mapping in ld.elf_so?  Thanks
to Michael Hitch, we've got performance back on R4000's with L2 cache,
but from what I understand there still could be a problem for R4000's
with no L2 cache - is the hpcmips in this boat (and what effective R4400
speed do these run at - a 60Mhz R4400 with 1MB of L2 takes about 12
hours to build NetBSD)?  If so, then the following patch from Jason
could speed things up quite a lot.

Simon.

--
>From: Jason Thorpe <thorpej@nas.nasa.gov>
>To: mhitch@netbsd.org
>Cc: simonb@netbsd.org, chuck@netbsd.org, chs@netbsd.org, mrg@netbsd.org
>Subject: uvm mmap/R4000 shlib problem
>Date: Fri, 29 Oct 1999 14:49:30 -0700

The following patch should fix the problem Michael reported to me today
on ICB, caused by rev 1.5 of map_object.c of ld.elf_so.  Basically,
mapping the entire library address space MAP_ANON was causing PMAP_PREFER()
to not be called, subsequently causing the actual shared library text to get
mapped in such a way as to cause a virtual cache alias conflict.

Anyone see any problems with this change?

Or, maybe we should add a new flag to mmap(2) (MAP_ALIGN?)?  I dunno... I
like the transparency of this, though it could lead to wasting address
space unnecessarily (i.e. in the case of mapping an anon region that
doens't need to be aligned to the alias boundary).

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>

Index: uvm_mmap.c
===================================================================
RCS file: /cvsroot/syssrc/sys/uvm/uvm_mmap.c,v
retrieving revision 1.35
diff -c -r1.35 uvm_mmap.c
*** uvm_mmap.c	1999/07/17 21:35:50	1.35
--- uvm_mmap.c	1999/10/29 21:42:40
***************
*** 1153,1160 ****
  	 */
  
  	if (flags & MAP_ANON) {
! 		
! 		foff = UVM_UNKNOWN_OFFSET;		
  		uobj = NULL;
  		if ((flags & MAP_SHARED) == 0)
  			/* XXX: defer amap create */
--- 1153,1171 ----
  	 */
  
  	if (flags & MAP_ANON) {
! #if 1
! 		/*
! 		 * Specify an offset of 0 so that uvm_map_findspace() via.
! 		 * uvm_map() will PMAP_PREFER the address for us.  This
! 		 * prevents alias problems if the following occurs:
! 		 *
! 		 *	- Anon region mapped.
! 		 *	- File mapped over anon region (using MAP_FIXED).
! 		 */
! 		foff = 0;
! #else
! 		foff = UVM_UNKNOWN_OFFSET;
! #endif
  		uobj = NULL;
  		if ((flags & MAP_SHARED) == 0)
  			/* XXX: defer amap create */

---