| Message ID | 20201008083029.9504-1-david@redhat.com |
|---|---|
| Headers | show |
| Series | virtio-mem: block size and address-assignment optimizations | expand |
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.
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
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
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(-)