[RFC] EAL: legacy memory fixed address translations
Don Wallwork
donw at xsightlabs.com
Wed Jul 27 23:43:28 CEST 2022
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.
More information about the dev
mailing list