mirror of https://github.com/xemu-project/xemu.git
82b54ef4c1
With preemption mode on, when we see a postcopy request that was requesting for exactly the page that we have preempted before (so we've partially sent the page already via PRECOPY channel and it got preempted by another postcopy request), currently we drop the request so that after all the other postcopy requests are serviced then we'll go back to precopy stream and start to handle that. We dropped the request because we can't send it via postcopy channel since the precopy channel already contains partial of the data, and we can only send a huge page via one channel as a whole. We can't split a huge page into two channels. That's a very corner case and that works, but there's a change on the order of postcopy requests that we handle since we're postponing this (unlucky) postcopy request to be later than the other queued postcopy requests. The problem is there's a possibility that when the guest was very busy, the postcopy queue can be always non-empty, it means this dropped request will never be handled until the end of postcopy migration. So, there's a chance that there's one dest QEMU vcpu thread waiting for a page fault for an extremely long time just because it's unluckily accessing the specific page that was preempted before. The worst case time it needs can be as long as the whole postcopy migration procedure. It's extremely unlikely to happen, but when it happens it's not good. The root cause of this problem is because we treat pss->postcopy_requested variable as with two meanings bound together, as the variable shows: 1. Whether this page request is urgent, and, 2. Which channel we should use for this page request. With the old code, when we set postcopy_requested it means either both (1) and (2) are true, or both (1) and (2) are false. We can never have (1) and (2) to have different values. However it doesn't necessarily need to be like that. It's very legal that there's one request that has (1) very high urgency, but (2) we'd like to use the precopy channel. Just like the corner case we were discussing above. To differenciate the two meanings better, introduce a new field called postcopy_target_channel, showing which channel we should use for this page request, so as to cover the old meaning (2) only. Then we leave the postcopy_requested variable to stand only for meaning (1), which is the urgency of this page request. With this change, we can easily boost priority of a preempted precopy page as long as we know that page is also requested as a postcopy page. So with the new approach in get_queued_page() instead of dropping that request, we send it right away with the precopy channel so we get back the ordering of the page faults just like how they're requested on dest. Reported-by: Manish Mishra <manish.mishra@nutanix.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Manish Mishra <manish.mishra@nutanix.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20220707185520.27583-1-peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> |
||
|---|---|---|
| .. | ||
| block-dirty-bitmap.c | ||
| block.c | ||
| block.h | ||
| channel-block.c | ||
| channel-block.h | ||
| channel.c | ||
| channel.h | ||
| colo-failover.c | ||
| colo.c | ||
| dirtyrate.c | ||
| dirtyrate.h | ||
| exec.c | ||
| exec.h | ||
| fd.c | ||
| fd.h | ||
| global_state.c | ||
| meson.build | ||
| migration.c | ||
| migration.h | ||
| multifd-zlib.c | ||
| multifd-zstd.c | ||
| multifd.c | ||
| multifd.h | ||
| page_cache.c | ||
| page_cache.h | ||
| postcopy-ram.c | ||
| postcopy-ram.h | ||
| qemu-file.c | ||
| qemu-file.h | ||
| ram.c | ||
| ram.h | ||
| rdma.c | ||
| rdma.h | ||
| savevm.c | ||
| savevm.h | ||
| socket.c | ||
| socket.h | ||
| target.c | ||
| tls.c | ||
| tls.h | ||
| trace-events | ||
| trace.h | ||
| vmstate-types.c | ||
| vmstate.c | ||
| xbzrle.c | ||
| xbzrle.h | ||
| yank_functions.c | ||
| yank_functions.h | ||