Re: [Qemu-devel] DIRTY_MEMORY_BLOCK_SIZE;

[Stefan Hajnoczi]

On Fri, Jun 30, 2017 at 12:26:10PM +0100, Dr. David Alan Gilbert wrote:
> * ali saeedi (address@hidden) 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.

signature.asc
Description: PGP signature