qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/1] Count used RAMBlock pages for migration_dirty_pages
Date: Fri, 21 Mar 2014 16:15:53 +0100	[thread overview]
Message-ID: <532C57A9.2060002@redhat.com> (raw)
In-Reply-To: <20140321132224.GA22211@work-vm>

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 '/rom@etc/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	other threads:[~2014-03-21 15:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 10:58 [Qemu-devel] [PATCH 1/1] Count used RAMBlock pages for migration_dirty_pages Dr. David Alan Gilbert (git)
2014-03-21 13:11 ` Juan Quintela
2014-03-21 13:22   ` Dr. David Alan Gilbert
2014-03-21 15:15     ` Paolo Bonzini [this message]
2014-03-21 15:45       ` Dr. David Alan Gilbert
2014-03-21 15:49         ` Paolo Bonzini
2014-03-21 16:08           ` Juan Quintela
2014-03-21 13:44 ` 陈梁
2014-03-21 14:41   ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=532C57A9.2060002@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).