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
Hello!
A lot of JITs are using tagged pointers for performance reasons which
means that the pointer bits beyond the 47th or 48th should be kept
untouched by the kernel.
On sparc64, MAX_PHYS_ADDRESS_BITS is currently defined as 53 meaning that
a lot of JITs crash on a sparc64 userspace [1].
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
>> 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
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
6 matches
Mail list logo
