Re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR kern/45746; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
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