On Fri, Nov 05, 2010 at 05:44:55PM +0000, Mindaugas Rasiukevicius wrote: > Masao Uebayashi <uebay...@tombi.co.jp> 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.
I believe I understand loaning *now*. I thought loaning has direction. It's not; someone who writes to it is penalized. I also understand why O->O doesn't exist. > > So again.. I would say it is something to revisit after XIP merge. I'm only trying to show that my XIP is not going in a totally wrong direction in big pictures. Unfortunately Chuck seems suspecting yet...