Re: XIP

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Masao Uebayashi <uebayasi%tombi.co.jp@localhost> wrote:
> > > Those mechanical vm_page -> vm_page_md changes done in pmaps have
> > > a valid point by itself.  Passing around vm_page pointer across
> > > pmap functions is unnecessary.  I'd rather say wrong.  All pmap
> > > needs is vm_page_md.
> > > 
> > > I'd propose to do this vm_page -> vm_page_md change in pmaps first
> > > in HEAD and sync the branch with it, rather than revert it.
> > 
> > that seems a bit premature, don't you think?
> > since you're already talking about redesigning it?
> > 
> > ... apparently not, you already checked it in.
> 
> It's not premature.  It clarifies that passing struct vm_page * to
> pmap is unnecessary at all.  We'll need to move those MD PV data
> structures to MI anyway.

There are ideas to move P->V tracking to MI, right.  However, you are
starting to re-design the pmap abstraction here - that is really out of
XIP project scope, and it definitely needs rmind-uvmplock merge first.

> > is your desire to control whether the mount accesses the device via
> > mappings, or just to be able to see whether or not the device is being
> > accessed via mappings?
> 
> Both.
> 
> My understanding is that mount options change only its internal behavior.
> I don't see how MNT_LOG and MNT_XIP differ.  Mount is done only by
> admins who know internals.  There may be cases where an XIP device
> is much slower than RAM, and page cache is wanted.
> 
> I also think that mount option is the only way to configure per-mount
> behavior.

Mount option seems quite useful to me.  Speaking of them.. I would also
like to add MNT_DIRECTIO. :)

> > I've thought about loaning and XIP again quite a bit, but in the
> > interest of actually sending this mail today, I'll leave this part for
> > later too.
> 
> I spent a little time for this...
> 
> Now uvm_loan() returns to a loaner an array of pointers to struct
> vm_page.  Which means that those struct vm_page's are shared among
> loaner and loanee.  The owner of those pages are recorded in
> vm_page::uanon and vm_page::uobject.
> 
> I'm thinking this design is broken.  At least A->A loan is impossible
> for no reason.  I think loanee should allocate (by kmem_alloc(9))
> a new *alias* vm_page, to keep loaning state.  Alias vm_page has
> a pointer to its new owner, and with a pointer to the *real* vm_page
> too.
> 
> uanon/uobject is also bad in that it obscures the 1:1 relationship
> of pages and owners.  These two members should be merged into a single
> void *pg_owner.  vm_page::loan_count is only for loaner.  Loaners
> of read-only, wired pages don't need to remember anything.

I do not think loaning is "broken", but I see where you are coming from.
"Owner-less" state i.e. when locker needs to resolve orphaned page brings
some obscurity.  Also, O->A loaning where we do trylocks (since we cannot
hold a reference on the object) is very messy.

Your idea about allocating extra meta-data in order to do the loaning
seems counter-productive, given the whole concept of loaning.

So again.. I would say it is something to revisit after XIP merge.

-- 
Mindaugas