| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: vram_dirty vs. shadow paging dirty tracking
Ian Pratt wrote:
When thinking about multithreading the device model, it occurred to me
that it's a little odd that we're doing a memcmp to determine which
portions of the VRAM has changed. Couldn't we just use dirty page
tracking in the shadow paging code? That should significantly lower
the
overhead of this plus I believe the infrastructure is already mostly
there in the shadow2 code.
Yep, its been in the roadmap doc for quite a while. However, the log
dirty code isn't ideal for this. We'd need to extend it to enable it to
be turned on for just a subset of the GFN range (we could use a xen
rangeset for this).
Okay, I was curious if the log dirty stuff could do ranges. I guess not.
Even so, I'm not super keen on the idea of tearing down and rebuilding
1024 PTE's up to 50 times a second.
A lower overhead solution would be to do scanning and resetting of the
dirty bits on the PTEs (and a global tlb flush).
Right, this is the approach I was assuming. There's really no use in
tearing down the whole PTE (since you would have to take an extraneous
read fault).
In the general case
this is tricky as the framebuffer could be mapped by multiple PTEs. In
practice, I believe this doesn't happen for either Linux or Windows.
I wouldn't think so, but showing my ignorance for a moment, does shadow2
not provide a mechanism to lookup VA's given a GFN? This lookup could
be cheap if the structures are built during shadow page table construction.
Sounds like this is a good long term goal but I think I'll stick with
the threading as an intermediate goal.
I've got a minor concern that threading isn't going to help us much when
dom0 is UP since the VGA scanning won't happen while an MMIO/PIO request
happens. With an SMP dom0, you could potentially do all the VGA
scanning on one processor ensuring that qemu-dm wasn't ever "busy" when
a request occurs. I'm slightly concerned though that having a thread
that's as CPU hungry as the VGA scanning may increase context-switches
during the MMIO/PIO handling which would actually hurt performance.
We'll see soon enough though.
Regards,
Anthony Liguori
There's always a good fallback of just returning 'all dirty' if the
heuristic is violated. Would be good to knock this up.
Best,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home