Re: [PATCH v4 07/13] ram-block-attribute: Introduce RamBlockAttribute to manage RAMBLock with guest_memfd

[David Hildenbrand <david@redhat.com>]

>>>
>>> Signed-off-by: Chenyi Qiang<chenyi.qiang@intel.com>
>>
>> <...>
>>
>>> +
>>> +int ram_block_attribute_realize(RamBlockAttribute *attr, MemoryRegion
>>> *mr)
>>> +{
>>> +    uint64_t shared_bitmap_size;
>>> +    const int block_size  = qemu_real_host_page_size();
>>> +    int ret;
>>> +
>>> +    shared_bitmap_size = ROUND_UP(mr->size, block_size) / block_size;
>>> +
>>> +    attr->mr = mr;
>>> +    ret = memory_region_set_generic_state_manager(mr,
>>> GENERIC_STATE_MANAGER(attr));
>>> +    if (ret) {
>>> +        return ret;
>>> +    }
>>> +    attr->shared_bitmap_size = shared_bitmap_size;
>>> +    attr->shared_bitmap = bitmap_new(shared_bitmap_size);
>>
>> Above introduces a bitmap to track the private/shared state of each 4KB
>> page. While functional, for large RAM blocks managed by guest_memfd,
>> this could lead to significant memory consumption.
>>
>> Have you considered an alternative like a Maple Tree or a generic
>> interval tree? Both are often more memory-efficient for tracking ranges
>> of contiguous states.
> 
> Maybe not necessary. The memory overhead is 1 bit per page
> (1/(4096*8)=0.003%). I think it is not too much.

It's certainly not optimal.

IIRC, QEMU already maintains 3 dirty bitmaps in
ram_list.dirty_memory (DIRTY_MEMORY_NUM = 3) for guest ram.

With KVM, we also allocate yet another dirty bitmap without 
KVM_MEM_LOG_DIRTY_PAGES.

Assuming a 4 TiB VM, a single bitmap should be 128 MiB.

-- 
Cheers,

David / dhildenb