Marcelo Tosatti wrote:
On Sun, Sep 07, 2008 at 11:42:18AM +0300, Avi Kivity wrote:
Marcelo Tosatti wrote:
From: Nick Piggin <[EMAIL PROTECTED]>
Provide a lockless pagetable walk function without fallback to mmap_sem
on error.
I would like to avoid this if possible. Not only is this a change to
the core (with backporting headaches),
Chris mentioned that the backport could use down_read_trylock(mmap_sem),
and zap the page on failure. Its a simple solution and it should be rare
for mmap_sem to be acquired in write mode.
Yes. Clever.
if we resync in atomic context
this can mean a long time spent with preemption disabled.
The resync time for a single page is comparable to prefetch_page (note
that prefetch_page with direct access via gfn_to_page_atomic is about
50% faster than the current one) plus the gfn->pfn pagetable walks.
These could be very expensive as the gfn->pfn mapping is essentially
random and too big to be cached. 512 cache misses is a lot of time -
perhaps upwards of 50 microseconds.
Snapshotting is a must here IMO -- and it avoids the need for a walk
completely.
It could simply resched based on need_resched after each page synced.
Would that cover your concern?
I guess it's better than nothing.
BTW, it might be interesting to spin_needbreak after resyncing a certain
number of pages.
We might get around the need by dropping the lock when we resync, fetch
the gfns without the lock, and after reacquiring it check whether we can
proceed or whether we need to abort and let the guest retry. We can
probably proceed unless one of two things have happened: an mmu page was
zapped, or out page was oos'ed while we were resyncing it.
This sounds more complicated. First you have to grab the lock twice for
each page synced. Secondly, the abort case due to oos'ed while resyncing
means the page has to be zapped.
It is complicated, yes.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
