NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


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

From: Izumi Tsutsui <>
Subject: Re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
Date: Wed, 28 Dec 2011 00:54:54 +0900

 >      - undocumented.
 >      - 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
  - 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

Home | Main Index | Thread Index | Old Index