All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Wei Yang <richardw.yang@linux.intel.com>,
	Igor Mammedov <imammedo@redhat.com>
Subject: [PATCH v3 0/6] virtio-mem: block size and address-assignment optimizations
Date: Thu,  8 Oct 2020 10:30:23 +0200	[thread overview]
Message-ID: <20201008083029.9504-1-david@redhat.com> (raw)



Let's try to detect the actual THP size and use it as default block size
(unless the page size of the backend indicates that THP don't apply).
Always allow to set a block size of 1 MiB, but warn if the configured block
size is smaller than the default. Handle large block sizes better, avoiding
a virtio-spec violation and optimizing address auto-detection.

For existing setups (x86-64), the default block size won't change (was, and
will be 2 MiB on anonymous memory). For existing x86-64 setups, the address
auto-detection won't change in relevant setups (esp., anonymous memory
and hugetlbfs with 2 MiB pages and no manual configuration of the block
size). I don't see the need for compatibility handling (especially, as
virtio-mem is still not considered production-ready).

Most of this is a preparation for future architectures, using hugetlbfs
to full extend, and using manually configured, larger block sizes
(relevant for vfio in the future).

v1 -> v2:
- Reordered patches to have fixes upfront
- Tweaked some patch descriptions
- "virtio-mem: Check that "memaddr" is multiples of the block size"
-- Renamed to "virtio-mem: Make sure "addr" is always multiples of the
   block size"
- "virtio-mem: Make sure "usable_region_size" is always multiples of the
   block size"
-- Added

v1 -> v2:
- Tweak some patch descriptions
- "virtio-mem: Probe THP size to determine default block size"
-- Beautify THP detection a bit.
-- Assume THP might only get used if the memory backend page size corresponds
   to the real hostpage size.
-- Use virtio_mem_default_block_size(RAMBlock *rb) to handle selection
   of the default block size for a RAMBlock.
-- Implement virtio_mem_get_block_size() as preparation for patch #5
- "memory-device: Add get_min_alignment() callback"
-- Simplify documentation.
- "virito-mem: Implement get_min_alignment()"
-- Simplify due to changes in patch #1.

David Hildenbrand (6):
  virtio-mem: Make sure "addr" is always multiples of the block size
  virtio-mem: Make sure "usable_region_size" is always multiples of the
    block size
  virtio-mem: Probe THP size to determine default block size
  memory-device: Support big alignment requirements
  memory-device: Add get_min_alignment() callback
  virito-mem: Implement get_min_alignment()

 hw/mem/memory-device.c         |  20 ++++--
 hw/virtio/virtio-mem-pci.c     |   7 ++
 hw/virtio/virtio-mem.c         | 113 +++++++++++++++++++++++++++++++--
 include/hw/mem/memory-device.h |  10 +++
 4 files changed, 140 insertions(+), 10 deletions(-)

-- 
2.26.2



             reply	other threads:[~2020-10-08  8:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08  8:30 David Hildenbrand [this message]
2020-10-08  8:30 ` [PATCH v3 1/6] virtio-mem: Make sure "addr" is always multiples of the block size David Hildenbrand
2020-10-08  8:30 ` [PATCH v3 2/6] virtio-mem: Make sure "usable_region_size" " David Hildenbrand
2020-10-08  8:30 ` [PATCH v3 3/6] virtio-mem: Probe THP size to determine default " David Hildenbrand
2020-10-08  8:30 ` [PATCH v3 4/6] memory-device: Support big alignment requirements David Hildenbrand
2020-10-08  8:30 ` [PATCH v3 5/6] memory-device: Add get_min_alignment() callback David Hildenbrand
2020-10-08  8:30 ` [PATCH v3 6/6] virito-mem: Implement get_min_alignment() David Hildenbrand
2020-10-22  8:10 ` [PATCH v3 0/6] virtio-mem: block size and address-assignment optimizations David Hildenbrand
2020-11-02 12:20   ` David Hildenbrand
2020-11-02 12:37     ` Michael S. Tsirkin

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=20201008083029.9504-1-david@redhat.com \
    --to=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richardw.yang@linux.intel.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.