[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/uvm
On Wed, Dec 22, 2010 at 11:13:52AM +0900, 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?
> I've already proven that __HAVE_VM_PAGE_MD pmaps don't need struct
> vm_page *.
> > There can be a common implementation of it for use by MD code but
> > that isn't the same as MI.
> > > Keep vm_physseg * + off_t array on stack. If UVM objects uses
> > > vm_page (e.g. vnode), its pager looks up vm_page -> vm_physseg *
> > > + off_t *once* and cache it on stack.
> > off_t is not the right type. psize_t would be more accurate.
Well, I want to make this MI. One of motivations to use vm_physseg
is to make page identity independent of machine-specific types
(paddr_t / psize_t). So that kernel modules are shared between
I see pmap as "MMU driver". paddr_t is an opaque type, which should
be used only for H/Ws that touch the physical bus (mainbus).
Main Index |
Thread Index |