Do you have any questions yet?

On Wed, Dec 22, 2010 at 12:52:21PM +0900, Masao Uebayashi wrote:
quoted text
> On Tue, Dec 21, 2010 at 06:33:53PM -0800, Matt Thomas wrote:
> > 
> > On Dec 21, 2010, at 6:13 PM, Masao Uebayashi wrote:
> > 
> > > On Tue, Dec 21, 2010 at 11:29:01AM -0800, Matt Thomas wrote:
> > >> 
> > >> On Dec 6, 2010, at 8:19 AM, Masao Uebayashi wrote:
> > >> 
> > >>> On Thu, Nov 25, 2010 at 11:32:39PM +0000, YAMAMOTO Takashi wrote:
> > >>>> [ adding cc: tech-kern@ ]
> > >>> 
> > >>> The basic idea is straightforward; always allocate vm_physseg for
> > >>> memories/devices.  If a vm_physseg is used as general purpose
> > >>> memory, you allocate vm_page[] (as vm_physseg::pgs).  If it's
> > >>> potentially mapped as cached, you allocate pvh (as vm_physseg:pvh).
> > >> 
> > >> Ewww.  How p->v is managed needs to be kept out of the MI code.
> > > 
> > > Could you elaborate the reason why so?
> > 
> > PowerPC OEA uses an inverted page table.  It's p->v works very differently.
> 
> True.
> 
> > 
> > > I've already proven that __HAVE_VM_PAGE_MD pmaps don't need struct
> > > vm_page *.
> > 
> > Well, pmap_page_* definitely need vm_page * since it's one of the arguments.
> 
> Yes, and vm_page * is used as page identity, right?
> 
> What I call "vm_page is used" means for example read/write'ing
> pg->flags.  In that sense, vm_page is not really used in any pmaps.
> 
> > 
> > >>>> any valid paddr_t value will belong to exactly one vm_phsseg?
> > >>> 
> > >>> That's the idea.  This would clarify mem(4) backend too.
> > >>> 
> > >>> Note that allocating vm_physseg for device segments is cheap.
> > >> 
> > >> that's depends on how much more expensive finding physseg gets.
> > > 
> > > "Finding physseg" == "(reverse) lookup of vm_page -> vm_physseg".
> > > It is done only once (for each page) in pagers that use vm_page.
> > > 
> > > Is the biggest concern lookup cost?  Then I'd point out that
> > > uvm_pageismanaged() in pmap_enter() should die.  Cacheability is
> > > decided by how VA is mapped.  Those uvm_pageismanaged() calls are
> > > both inefficient and wrong.
> > 
> > Not all pmaps use that.  Instead, we should have a PMAP_UNMANAGED
> > flag passed to pmap_enter since the caller probably know the
> > answer.
> 
> s/probably know/know/
> 
> IMO cacheability is always explicitly specified by UVM.
> 
> Cacheability is decided by how VA is mapped, i.e., shared or not.
> Vnode are shared but read-only, so it's cacheable.  Device registers
> are shared between CPU and H/W, so it can't be cacheable.

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635