Andrea Arcangeli wrote: > On Wed, Apr 02, 2008 at 07:32:35AM +0300, Avi Kivity wrote: > >> It ought to work. gfn_to_hfn() (old gfn_to_page) will still need to take a >> refcount if possible. >> > > This reminds me, that mmu notifiers we could implement gfn_to_hfn only > with follow_page and skip the refcounting on the struct page. > > I'm not suggesting that though, the refcount makes the code more > robust IMHO, and notably it allows to run on kernels without mmu > notifiers. > >
Isn't it faster though? We don't need to pull in the cacheline containing the struct page anymore. We could hack something to make pre mmu notifier kernels work. > > I'm unsure if it's good to add struct pages for non-ram, I find it > slightly confusing and not the right thing, it takes memory for stuff > that can't happen (refcounting only makes sense if the page finally > goes in the freelist when count reaches 0, and PG_dirty/referenced > bits and the like don't make sense either for non-ram or > reserved-ram). So I'm not sure the vmemmap trick is the best. > > I thought we'd meet with resistance to that idea :) though I'd like to point out that struct pages to exist for mmio on some machines (those with >= 4GB). >> This will increase the potential for type errors, so maybe we need to make >> gfn_t and hfn_t distinct structures, and use accessors to get the actual >> values. >> > > That's also a possibility. If we go for this then hfn_t is probably a > better name as it's less likely to collide with core kernel VM > code. Otherwise perhaps "pfn" can be used instead of hfn, it's up to > you ;). > I guess we can move to pfn, they're unambiguous enough. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
