qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/1] Count used RAMBlock pages for migration_dir


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 1/1] Count used RAMBlock pages for migration_dirty_pages
Date: Fri, 21 Mar 2014 16:15:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Il 21/03/2014 14:22, Dr. David Alan Gilbert ha scritto:
I don't think they overlap, but I worry that the end of one block
and the start of the next might be on the same page.
The code that got me worried was migration_bitmap_sync_range
that seemd to be general; but actually that's worrying about 64bit words
not pages.
What happens with things like '/address@hidden/table-loader' which is only
4k on x86 when they are on boxes with bigger target_page.

Do you mean bigger host page?

RAM sizes are always rounded up to target page size:

    size = TARGET_PAGE_ALIGN(size);

If I understand correctly all that matters here is ram addresses have no remainder WRT target page sizes.

Host page sizes matter only for KVM (see hpratio in cpu_physical_memory_set_dirty_lebitmap in include/exec/ram_addr.h). In this case dirtying a 4K area also dirties 12K of adjacent ram_addr_t. Things could go wrong if those ram_addr_t's are not part of any RAMBlock, because in that case you will loop endlessly (I think). But this is not something your patch introduces.

So it looks like your patch could also fix the problem Juan reported at http://article.gmane.org/gmane.comp.emulators.qemu/247462 -- but perhaps only on hosts where !KVM || TARGET_PAGE_SIZE==getpagesize().

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]