Nicholas Piggin writes:
> Aneesh Kumar K.V's on February 19, 2019 4:00 pm:
>> On 2/19/19 11:28 AM, Nicholas Piggin wrote:
>>> Aneesh Kumar K.V's on February 17, 2019 3:16 pm:
This patch maps vmap, IO and vmemap regions in the 0xc address range
instead of the current 0xd and 0xf range.
Aneesh Kumar K.V's on February 19, 2019 4:00 pm:
> On 2/19/19 11:28 AM, Nicholas Piggin wrote:
>> Aneesh Kumar K.V's on February 17, 2019 3:16 pm:
>>> This patch maps vmap, IO and vmemap regions in the 0xc address range
>>> instead of the current 0xd and 0xf range. This brings the mapping closer
On 2/19/19 11:28 AM, Nicholas Piggin wrote:
Aneesh Kumar K.V's on February 17, 2019 3:16 pm:
This patch maps vmap, IO and vmemap regions in the 0xc address range
instead of the current 0xd and 0xf range. This brings the mapping closer
to radix translation mode.
What was the reason for that
Aneesh Kumar K.V's on February 17, 2019 3:16 pm:
> This patch maps vmap, IO and vmemap regions in the 0xc address range
> instead of the current 0xd and 0xf range. This brings the mapping closer
> to radix translation mode.
What was the reason for that address layout in the first place?
Thanks,
This patch maps vmap, IO and vmemap regions in the 0xc address range
instead of the current 0xd and 0xf range. This brings the mapping closer
to radix translation mode.
With hash 64K page size each of this region is 512TB whereas with 4K config
we are limitted by the max page table range of 64TB
