NetBSD Problem Report #45746

From yamt@NetBSD.org  Tue Dec 27 08:43:57 2011
Return-Path: <yamt@NetBSD.org>
Received: by www.NetBSD.org (Postfix, from userid 1270)
	id D730863BC36; Tue, 27 Dec 2011 08:43:57 +0000 (UTC)
Message-Id: <20111227084357.D730863BC36@www.NetBSD.org>
Date: Tue, 27 Dec 2011 08:43:57 +0000 (UTC)
From: yamt@NetBSD.org
Reply-To: yamt@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
X-Send-Pr-Version: 3.95

>Number:         45746
>Category:       kern
>Synopsis:       UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 27 08:45:00 +0000 2011
>Last-Modified:  Tue Dec 27 15:55:01 +0000 2011
>Originator:     YAMAMOTO Takashi
>Release:        NetBSD current
>Organization:

>Environment:


>Description:
	UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems

	- undocumented.

	- confusing as it abuses existing function parameters for different
	  purposes.

	- it's unclear what kind of color should match with what.  pa, va, ...
	  the use in uvm_pager.c imposes useless restrictions for ports where 
	  aliasing is not a problem.  eg. x86.

	- it's unclear how it should interact with PMAP_PREFER.

>How-To-Repeat:
	code inspection.
>Fix:


>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
Date: Tue, 27 Dec 2011 21:38:46 +0900

 Just FYI,
 http://mail-index.NetBSD.org/netbsd-bugs/2011/11/15/msg024876.html

 - we need to handle both VA colors and PA colors separately
   (I'm not sure if we should also put them into uvmexp)

 - currently uvm_pagealloc_pgfl() is used to allocate a specific color
   page to avoid aliasing for VA colors, but it just tries to search
   the specified color and may still return colormiss++ pages

 ---
 Izumi Tsutsui

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, yamt@NetBSD.org
Subject: re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
Date: Wed, 28 Dec 2011 00:44:04 +1100

 i'm pretty sure this affects sparc64 where VA colours aren't
 matching PA colours, but we have to conflate them.


 .mrg.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
Date: Wed, 28 Dec 2011 00:54:54 +0900

 > 	UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
 > 
 > 	- undocumented.

 Indeed.

 > 	- confusing as it abuses existing function parameters for different
 > 	  purposes.

 Is it (using "align" as a color index if COLORMATCH is specified)
 acceptable if it's documented? ;-p

 > 	- it's unclear how it should interact with PMAP_PREFER.

 I guess the COLORMATCH was introduced to avoid *all* possible
 cache aliases on VIPT systems (i.e. on MIPS),
 using strict "PA index == VA index" PV mapping strategy.

 I think PMAP_PREFER can avoid aliases only if we have a hint
 on allocating VA. (well I'm not a VM guy)

 I think COLORMATCH is also used on
  - allocating physical pages for existing VA per the mapping restriction
    (uvm_pagealloc()?)
  - allocating new shared VA without alias
    (uvm_map_findspace(), uvm_pagermapin(), page loaning etc?
     I guess PMAP_PREFER is no longer necessary if COLORMATCH is specified
     and PMAP_PREFER is still needed for VIVT systems, but I'm not sure)
  - mapping unmanaged pages per the mapping restriction
    (to use pmap_kenter_pa() instead of pmap_enter(), i.e.
     no PV map tracking is necessary for future cache flush
     and uncached mappings if no aliases will happen on the restriction)

 I don't know what happens on trying shared mapping VAs which have
 different colors though.


 BTW, what's the current status of yamt-kmem branch?

 ---
 Izumi Tsutsui

>Unformatted:

Home	PR Database Search