From: John Paul Adrian Glaubitz
Date: Fri, 24 May 2019 20:51:33 +0200
> On 5/24/19 6:20 PM, David Miller wrote:
>>> On the other hand, arm64 currently allows the virtual address size
>>> to be configurable, currently defaulting to 48 bits [2, 3]. I was
>>> therefore wondering whether we could
On 5/24/19 6:20 PM, David Miller wrote:
>> On the other hand, arm64 currently allows the virtual address size
>> to be configurable, currently defaulting to 48 bits [2, 3]. I was
>> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
>> configurable as well to be able to support
From: John Paul Adrian Glaubitz
Date: Fri, 24 May 2019 12:24:53 +0200
> On the other hand, arm64 currently allows the virtual address size
> to be configurable, currently defaulting to 48 bits [2, 3]. I was
> therefore wondering whether we could make MAX_PHYS_ADDRESS_BITS [4]
> configurable as
>> On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that
>> a lot of JITs crash on a sparc64 userspace [1].
>
> Correction, it shouldn't be MAX_PHYS_ADDRESS_BITS but sparc64_va_hole_top as
> defined in mm/init_64.c.
That sounds like a good compromise, considering that
On 5/24/19 12:24 PM, John Paul Adrian Glaubitz wrote:
> On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that
> a lot of JITs crash on a sparc64 userspace [1].
Correction, it shouldn't be MAX_PHYS_ADDRESS_BITS but sparc64_va_hole_top as
defined in mm/init_64.c.
Thanks,
Adrian
5 matches
Mail list logo
