On 7/27/2022 4:36 PM, Dmitry Kozlyuk wrote:
I now understand more about_why_ you want this feature but became less confident_what_ do you're proposing specifically.
Let me try to give a trivial example of how it would work to make sure we're on the same page and then we can get back to details.. Say you have a system with 4 huge pages that are 1G each and the physical addresses are 10, 11, 17 and 22G. If we map 13G of virtual address space, that will be enough to cover all of the huge page physical addresses. If the VA region starts at 1G, all of the hugepage PAs can be mapped into that region as shown below under Proposed heading. For comparison, existing mapping that would be done in legacy mode is shown under the Current heading. Proposed Current (Legacy) VA | PA VA | PA ----+---- ----+---- 1G | 10G 1G | 10G 2G | 11G 2G | 11G 3G | - 3G | - 4G | - 4G | 17G 5G | - 5G | - 6G | - 6G | 22G 7G | - 8G | 17G 9G | - 10G | - 11G | - 12G | - 13G | 22G So in this example, we have a fixed offset of 9G to translate between VA to PA or vice versa.This works whether the huge pages happen to be allocated statically (legacy mode) or dynamically. The unused VA address space from 3G-7G and 9G-12G can be unmapped in just two unmap calls. This is a very nice property in that it makes address translations trivial without requiring costly searches. This property also makes debugging easier.
