Open GoogleCodeExporter opened 9 years ago
So, looks like there's someone else playing in the virtual memory area.
Specifically, non-virtual machine thread.
First I wonder how this can be possible: the execution state of that thread is
not tracked in the VM, so it cannot be restarted from snapshot. I guess that
virtual machine thread that owns the buffer will treat its content as
indeterminate and will have to restart its request to that non-virtual machine
thread after restart from snapshot.
If so, then we can provide rw lock for the whole VM: ordinary threads will
acquire it for reading and the snapper will acquire it for writing. Probably
this r-acquisition may be done from the pagefault handlers.
If that makes sense I will try to implement it.
Original comment by jcmvb...@gmail.com
on 12 Oct 2011 at 10:08
Can it be some delayed pageing activity?
As for rw locks - we'll surely need 'em anyway, so I think implementing rw
mutex is good idea in any case.
Original comment by d...@dz.ru
on 14 Oct 2011 at 12:40
Paging activity is synchronous and always belong to a thread.
So it can be whatever paging activity but not in virtual machine thread.
Original comment by jcmvb...@gmail.com
on 14 Oct 2011 at 12:49
io callbacks are async!
Original comment by d...@dz.ru
on 14 Oct 2011 at 1:21
Please correct me if I'm wrong:
IO by itself cannot raise a pagefault since it needs physical memory to start
transfer to/from it.
IO callback that results from the pagein or pageout initiated by the pagefault
is completely nested into the pagefault handler, so it is synchronous to its
thread.
Original comment by jcmvb...@gmail.com
on 14 Oct 2011 at 1:53
I believe pageins are nested (thread waits for page), and pageouts are not -
thread is free to go...
Original comment by d...@dz.ru
on 14 Oct 2011 at 2:55
Thanks, I need to review it in greater detail.
Original comment by jcmvb...@gmail.com
on 14 Oct 2011 at 3:02
Original issue reported on code.google.com by
dmitry.zavalishin@gmail.com
on 11 Oct 2011 at 7:47