|
From: | Denis Plotnikov |
Subject: | Re: [PATCH v0 3/4] migration: add background snapshot |
Date: | Wed, 29 Jul 2020 16:57:05 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 29.07.2020 16:27, Dr. David Alan Gilbert wrote:
.../** * ram_find_and_save_block: finds a dirty page and sends it to f * @@ -1782,6 +2274,7 @@ static int ram_find_and_save_block(RAMState *rs, bool last_stage) pss.block = rs->last_seen_block; pss.page = rs->last_page; pss.complete_round = false; + pss.page_copy = NULL; if (!pss.block) { pss.block = QLIST_FIRST_RCU(&ram_list.blocks); @@ -1794,11 +2287,30 @@ static int ram_find_and_save_block(RAMState *rs, bool last_stage) if (!found) { /* priority queue empty, so just search for something dirty */ found = find_dirty_block(rs, &pss, &again); + + if (found && migrate_background_snapshot()) { + /* + * make a copy of the page and + * pass it to the page search status + */ + int ret; + ret = ram_copy_page(pss.block, pss.page, &pss.page_copy);I'm a bit confused about why we hit this; the way I'd thought about your code was we turn on the write faulting, do one big save and then fixup the faults as the save is happening (doing the copies) as the writes hit; so when does this case hit?To make it more clear, let me draw the whole picture: When we do background snapshot, the vm is paused untill all vmstate EXCEPT ram is saved. RAM isn't written at all. That vmstate part is saved in the temporary buffer. Then all the RAM is marked as read-only and the vm is un-paused. Note that at this moment all vm's vCPUs are running and can touch any part of memory. After that, the migration thread starts writing the ram content. Once a memory chunk is written, the write protection is removed for that chunk. If a vCPU wants to write to a memory page which is write protected (hasn't been written yet), this write is intercepted, the memory page is copied and queued for writing, the memory page write access is restored. The intention behind of that, is to allow vCPU to work with a memory page as soon as possible.So I think I'm confusing this description with the code I'm seeing above. The code above, being in ram_find_and_save_block makes me think it's calling ram_copy_page for every page at the point just before it writes it - I'm not seeing how that corresponds to what you're saying about it being queued when the CPU tries to write it.
You are right. The code should be different there.It seems that I confused myself as well by sending a wrong version of the patch set. I think this series should be re-send so my description above corresponds to the code.
Thanks, Denis
Once all the RAM has been written, the rest of the vmstate is written from the buffer. This needs to be so because some of the emulated devices, saved in that buffered vmstate part, expects the RAM content to be available first on its loading.Right, same type of problem as postcopy. DaveI hope this description will make things more clear. If not, please let me know, so I could add more details. Denis-- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK-- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
[Prev in Thread] | Current Thread | [Next in Thread] |