[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/45746: UVM_KMF_COLORMATCH/UVM_FLAG_COLORMATCH problems
The following reply was made to PR kern/45746; it has been noted by GNATS.
From: Izumi Tsutsui <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.
> - confusing as it abuses existing function parameters for different
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?
Main Index |
Thread Index |