Skip to content
  • David Hildenbrand's avatar
    cb83ba8c
    softmmu/memory_mapping: optimize for RamDiscardManager sections · cb83ba8c
    David Hildenbrand authored
    
    
    virtio-mem logically plugs/unplugs memory within a sparse memory region
    and notifies via the RamDiscardManager interface when parts become
    plugged (populated) or unplugged (discarded).
    
    Currently, we end up (via the two users)
    1) zeroing all logically unplugged/discarded memory during TPM resets.
    2) reading all logically unplugged/discarded memory when dumping, to
       figure out the content is zero.
    
    1) is always bad, because we assume unplugged memory stays discarded
       (and is already implicitly zero).
    2) isn't that bad with anonymous memory, we end up reading the zero
       page (slow and unnecessary, though). However, once we use some
       file-backed memory (future use case), even reading will populate memory.
    
    Let's cut out all parts marked as not-populated (discarded) via the
    RamDiscardManager. As virtio-mem is the single user, this now means that
    logically unplugged memory ranges will no longer be included in the
    dump, which results in smaller dump files and faster dumping.
    
    virtio-mem has a minimum granularity of 1 MiB (and the default is usually
    2 MiB). Theoretically, we can see quite some fragmentation, in practice
    we won't have it completely fragmented in 1 MiB pieces. Still, we might
    end up with many physical ranges.
    
    Both, the ELF format and kdump seem to be ready to support many
    individual ranges (e.g., for ELF it seems to be UINT32_MAX, kdump has a
    linear bitmap).
    
    Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
    Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Eduardo Habkost <ehabkost@redhat.com>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Claudio Fontana <cfontana@suse.de>
    Cc: Thomas Huth <thuth@redhat.com>
    Cc: "Alex Bennée" <alex.bennee@linaro.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Laurent Vivier <lvivier@redhat.com>
    Cc: Stefan Berger <stefanb@linux.ibm.com>
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Message-Id: <20210727082545.17934-5-david@redhat.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    cb83ba8c
    softmmu/memory_mapping: optimize for RamDiscardManager sections
    David Hildenbrand authored
    
    
    virtio-mem logically plugs/unplugs memory within a sparse memory region
    and notifies via the RamDiscardManager interface when parts become
    plugged (populated) or unplugged (discarded).
    
    Currently, we end up (via the two users)
    1) zeroing all logically unplugged/discarded memory during TPM resets.
    2) reading all logically unplugged/discarded memory when dumping, to
       figure out the content is zero.
    
    1) is always bad, because we assume unplugged memory stays discarded
       (and is already implicitly zero).
    2) isn't that bad with anonymous memory, we end up reading the zero
       page (slow and unnecessary, though). However, once we use some
       file-backed memory (future use case), even reading will populate memory.
    
    Let's cut out all parts marked as not-populated (discarded) via the
    RamDiscardManager. As virtio-mem is the single user, this now means that
    logically unplugged memory ranges will no longer be included in the
    dump, which results in smaller dump files and faster dumping.
    
    virtio-mem has a minimum granularity of 1 MiB (and the default is usually
    2 MiB). Theoretically, we can see quite some fragmentation, in practice
    we won't have it completely fragmented in 1 MiB pieces. Still, we might
    end up with many physical ranges.
    
    Both, the ELF format and kdump seem to be ready to support many
    individual ranges (e.g., for ELF it seems to be UINT32_MAX, kdump has a
    linear bitmap).
    
    Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
    Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Eduardo Habkost <ehabkost@redhat.com>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Cc: Igor Mammedov <imammedo@redhat.com>
    Cc: Claudio Fontana <cfontana@suse.de>
    Cc: Thomas Huth <thuth@redhat.com>
    Cc: "Alex Bennée" <alex.bennee@linaro.org>
    Cc: Peter Xu <peterx@redhat.com>
    Cc: Laurent Vivier <lvivier@redhat.com>
    Cc: Stefan Berger <stefanb@linux.ibm.com>
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Message-Id: <20210727082545.17934-5-david@redhat.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
Loading