mbox series

[v3,0/6] virtio-mem: block size and address-assignment optimizations

Message ID 20201008083029.9504-1-david@redhat.com
Headers show
Series virtio-mem: block size and address-assignment optimizations | expand

Message

David Hildenbrand Oct. 8, 2020, 8:30 a.m. UTC
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(-)

Comments

David Hildenbrand Oct. 22, 2020, 8:10 a.m. UTC | #1
On 08.10.20 10:30, David Hildenbrand wrote:
> 
> 
> 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).

Ping.
David Hildenbrand Nov. 2, 2020, 12:20 p.m. UTC | #2
On 22.10.20 10:10, David Hildenbrand wrote:
> On 08.10.20 10:30, David Hildenbrand wrote:

>>

>>

>> 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).

> 

> Ping.

> 


Ping, MST?

-- 
Thanks,

David / dhildenb
Michael S. Tsirkin Nov. 2, 2020, 12:37 p.m. UTC | #3
On Mon, Nov 02, 2020 at 01:20:11PM +0100, David Hildenbrand wrote:
> On 22.10.20 10:10, David Hildenbrand wrote:
> > On 08.10.20 10:30, David Hildenbrand wrote:
> > > 
> > > 
> > > 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).
> > 
> > Ping.
> > 
> 
> Ping, MST?

Applied, thanks!

> -- 
> Thanks,
> 
> David / dhildenb