[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/uvm
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.
> > 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
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.
Main Index |
Thread Index |