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