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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.