qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: ali saeedi <ali.saeedi56@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] DIRTY_MEMORY_BLOCK_SIZE;
Date: Wed, 5 Jul 2017 17:06:41 +0100	[thread overview]
Message-ID: <20170705160640.GB2284@work-vm> (raw)
In-Reply-To: <20170705151030.GF29910@stefanha-x1.localdomain>

* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> On Fri, Jun 30, 2017 at 12:26:10PM +0100, Dr. David Alan Gilbert wrote:
> > * ali saeedi (ali.saeedi56@gmail.com) wrote:
> > > Hello
> > > what does 'DIRTY_MEMORY_BLOCK_SIZE' mean?
> > > is it the number of words in a block? or number of pages in a block? or
> > > number of bytes in a block?
> > > thanks a lot
> > 
> > (cc'ing Stefan)
> > I think that DIRTY_MEMORY_BLOCK_SIZE is the number of TARGET_PAGEs
> > within one DIRTY_MEMORY_BLOCK
> > So with the common 4k target page that's 4k*256k*8=8GB/dirty memory
> > block - note these are just the size of structure sin qemu, it's still
> > got the ranularity ot mark individual target pages as dirty.
> 
> Right, the calculation is shown in the comment above the code:
> 
>  *   rcu_read_lock();
>  *
>  *   DirtyMemoryBlocks *blocks =
>  *       atomic_rcu_read(&ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION]);
>  *
>  *   ram_addr_t idx = (addr >> TARGET_PAGE_BITS) / DIRTY_MEMORY_BLOCK_SIZE;
>  *   unsigned long *block = blocks.blocks[idx];
>  *   ...access block bitmap...
>  *
>  *   rcu_read_unlock();
> 
> Rather than focussing on DIRTY_MEMORY_BLOCK_SIZE, make sure you
> understand how DirtyMemoryBlocks works.  It is an array of bitmap
> pointers.
> 
> Instead of directly indexing into a single huge dirty memory bitmap,
> QEMU divides the dirty memory bitmap into fixed-sized chunks.  Each
> chunk covers DIRTY_MEMORY_BLOCK_SIZE pages.
> 
> The reason for this layer of indirection is so that the dirty memory
> bitmap can be accessed without taking a traditional lock (just RCU) and
> also supports memory hotplug.
> 
> Without indirection it would be difficult to grow the bitmap while other
> threads are writing to it.  Thanks to the indirection, it's possible to
> allocate new chunks and continue using the old chunks when growth
> occurs.

I guess this works like the old non-chunk version, in that there's no
direct correspondence between DirtyMemoryBlocks and RAMBlock's - i.e.
one RAMBlock might span two DirtyMemoryBlocks even if it's smaller
than DIRTY_MEMORY_BLOCK_SIZE.

Dave


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-07-05 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30 10:47 [Qemu-devel] DIRTY_MEMORY_BLOCK_SIZE; ali saeedi
2017-06-30 11:26 ` Dr. David Alan Gilbert
2017-07-05 15:10   ` Stefan Hajnoczi
2017-07-05 16:06     ` Dr. David Alan Gilbert [this message]
2017-07-06  9:44       ` Stefan Hajnoczi

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=20170705160640.GB2284@work-vm \
    --to=dgilbert@redhat.com \
    --cc=ali.saeedi56@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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).