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