tech-kern archive

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

Re: CVS commit: src/sys/uvm

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

Home | Main Index | Thread Index | Old Index