[PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

Like la264 only has 40 effective bits of virtual address space.
When TRY_EMPTY_VM_SPACE is set to 0x8000000000, it just exceeds
the range of 40-bit virtual address, causing the mmap mapping
to fail, thus causing the pch function to fail. To be compatible
with this situation set the macro to 0x1000000000.

gcc/ChangeLog:

	* config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value of
	the macro to 0x1000000000.
---
 gcc/config/host-linux.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
index a891651a7b6..d1aa7ab28ca 100644
--- a/gcc/config/host-linux.cc
+++ b/gcc/config/host-linux.cc
@@ -99,7 +99,7 @@
 #elif defined(__riscv) && defined (__LP64__)
 # define TRY_EMPTY_VM_SPACE	0x1000000000
 #elif defined(__loongarch__) && defined(__LP64__)
-# define TRY_EMPTY_VM_SPACE	0x8000000000
+# define TRY_EMPTY_VM_SPACE	0x1000000000
 #else
 # define TRY_EMPTY_VM_SPACE	0
 #endif
-- 
2.31.1

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Xi Ruoyao]

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
> Like la264 only has 40 effective bits of virtual address space.

I'm OK with the change.  But the VA length is configurable building the
kernel.  Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller page
size"?

> When TRY_EMPTY_VM_SPACE is set to 0x8000000000, it just exceeds
> the range of 40-bit virtual address, causing the mmap mapping
> to fail, thus causing the pch function to fail. To be compatible
> with this situation set the macro to 0x1000000000.
> 
> gcc/ChangeLog:
> 
>         * config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value
> of
>         the macro to 0x1000000000.
> ---
>  gcc/config/host-linux.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
> index a891651a7b6..d1aa7ab28ca 100644
> --- a/gcc/config/host-linux.cc
> +++ b/gcc/config/host-linux.cc
> @@ -99,7 +99,7 @@
>  #elif defined(__riscv) && defined (__LP64__)
>  # define TRY_EMPTY_VM_SPACE    0x1000000000
>  #elif defined(__loongarch__) && defined(__LP64__)
> -# define TRY_EMPTY_VM_SPACE    0x8000000000
> +# define TRY_EMPTY_VM_SPACE    0x1000000000
>  #else
>  # define TRY_EMPTY_VM_SPACE    0
>  #endif

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

在 2023/2/21 下午3:41, Xi Ruoyao 写道:
> On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
>> Like la264 only has 40 effective bits of virtual address space.
> I'm OK with the change.  But the VA length is configurable building the
> kernel.  Is there any specific reason LA264 has to use the 40-bit
> configuration, or should we reword the commit message like "for
> supporting the configuration with less page table level or smaller page
> size"?

I consulted with my colleagues who are working on the kernel,

it looks like this:

The la264 chip desgn is physically 40-bit virtual address.

User mode and kernel mode each account for half:

User mode :    0x0-0x7f ffff ffff

Kernel mode:  0xffff ff80 0000 0000 -0xffff ffff ffff ffff

The high bit is the sign extension of bit39.


>
>> When TRY_EMPTY_VM_SPACE is set to 0x8000000000, it just exceeds
>> the range of 40-bit virtual address, causing the mmap mapping
>> to fail, thus causing the pch function to fail. To be compatible
>> with this situation set the macro to 0x1000000000.
>>
>> gcc/ChangeLog:
>>
>>          * config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value
>> of
>>          the macro to 0x1000000000.
>> ---
>>   gcc/config/host-linux.cc | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
>> index a891651a7b6..d1aa7ab28ca 100644
>> --- a/gcc/config/host-linux.cc
>> +++ b/gcc/config/host-linux.cc
>> @@ -99,7 +99,7 @@
>>   #elif defined(__riscv) && defined (__LP64__)
>>   # define TRY_EMPTY_VM_SPACE    0x1000000000
>>   #elif defined(__loongarch__) && defined(__LP64__)
>> -# define TRY_EMPTY_VM_SPACE    0x8000000000
>> +# define TRY_EMPTY_VM_SPACE    0x1000000000
>>   #else
>>   # define TRY_EMPTY_VM_SPACE    0
>>   #endif

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[WANG Xuerui]

Hi,

On 2023/2/21 21:03, Lulu Cheng wrote:
>
> 在 2023/2/21 下午3:41, Xi Ruoyao 写道:
>> On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
>>> Like la264 only has 40 effective bits of virtual address space.
>> I'm OK with the change.  But the VA length is configurable building the
>> kernel.  Is there any specific reason LA264 has to use the 40-bit
>> configuration, or should we reword the commit message like "for
>> supporting the configuration with less page table level or smaller page
>> size"?
>
> I consulted with my colleagues who are working on the kernel,
>
> it looks like this:
>
> The la264 chip desgn is physically 40-bit virtual address.
>
> User mode and kernel mode each account for half:
>
> User mode :    0x0-0x7f ffff ffff
>
> Kernel mode:  0xffff ff80 0000 0000 -0xffff ffff ffff ffff
>
> The high bit is the sign extension of bit39.
>
Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, they 
all indicate that the guessed range should be "likely free" -- that 
implies "usable". Given the common VM allocation behavior, we want 
TRY_EMPTY_VM_SPACE to point at a reasonably high place in the VA so it's 
"likely free".

So IMO the point is, will there be any LoongArch HW in the foreseeable 
future, with less than maybe 40 bits of VA? If the answer is "no" then a 
TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling would be appropriate. 
Otherwise you may have to choose a value near or even below a 32-bit 
VA's upper limit: according to the ISA manual Volume 1, Section 2.1.5, 
"typical VALEN is in the range of [40, 48]"; also see Section 5.2.3, 
RDVA can be as large as 8, so the actual VA space could theoretically be 
as narrow as 40-8=32 bits.

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

在 2023/2/21 下午9:56, WANG Xuerui 写道:
> Hi,
>
> On 2023/2/21 21:03, Lulu Cheng wrote:
>>
>> 在 2023/2/21 下午3:41, Xi Ruoyao 写道:
>>> On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
>>>> Like la264 only has 40 effective bits of virtual address space.
>>> I'm OK with the change.  But the VA length is configurable building the
>>> kernel.  Is there any specific reason LA264 has to use the 40-bit
>>> configuration, or should we reword the commit message like "for
>>> supporting the configuration with less page table level or smaller page
>>> size"?
>>
>> I consulted with my colleagues who are working on the kernel,
>>
>> it looks like this:
>>
>> The la264 chip desgn is physically 40-bit virtual address.
>>
>> User mode and kernel mode each account for half:
>>
>> User mode :    0x0-0x7f ffff ffff
>>
>> Kernel mode:  0xffff ff80 0000 0000 -0xffff ffff ffff ffff
>>
>> The high bit is the sign extension of bit39.
>>
> Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
> they all indicate that the guessed range should be "likely free" -- 
> that implies "usable". Given the common VM allocation behavior, we 
> want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the VA 
> so it's "likely free".
>
> So IMO the point is, will there be any LoongArch HW in the foreseeable 
> future, with less than maybe 40 bits of VA? If the answer is "no" then 
> a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling would be appropriate. 
> Otherwise you may have to choose a value near or even below a 32-bit 
> VA's upper limit: according to the ISA manual Volume 1, Section 2.1.5, 
> "typical VALEN is in the range of [40, 48]"; also see Section 5.2.3, 
> RDVA can be as large as 8, so the actual VA space could theoretically 
> be as narrow as 40-8=32 bits.


Yes, I agree with your point of view this is looking for a "likely free" 
virtual memory space.


But if I want to support chips with less than 40-bit virtual addresses, 
then the value of this macro needs to be set small.

I think setting this value small will increase the probability of 
virtual address mapping failure.

Chips with less than 40-bit virtual address space are small chips for 
embedded use.

The purpose of pch is to make compilation faster, but I think we rarely 
compile on embedded systems. So this situation may not be within our 
consideration.

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[WANG Xuerui]

On 2023/2/22 17:30, Lulu Cheng wrote:
>
> 在 2023/2/21 下午9:56, WANG Xuerui 写道:
>> Hi,
>>
>> On 2023/2/21 21:03, Lulu Cheng wrote:
>>>
>>> 在 2023/2/21 下午3:41, Xi Ruoyao 写道:
>>>> On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
>>>>> Like la264 only has 40 effective bits of virtual address space.
>>>> I'm OK with the change.  But the VA length is configurable building 
>>>> the
>>>> kernel.  Is there any specific reason LA264 has to use the 40-bit
>>>> configuration, or should we reword the commit message like "for
>>>> supporting the configuration with less page table level or smaller 
>>>> page
>>>> size"?
>>>
>>> I consulted with my colleagues who are working on the kernel,
>>>
>>> it looks like this:
>>>
>>> The la264 chip desgn is physically 40-bit virtual address.
>>>
>>> User mode and kernel mode each account for half:
>>>
>>> User mode :    0x0-0x7f ffff ffff
>>>
>>> Kernel mode:  0xffff ff80 0000 0000 -0xffff ffff ffff ffff
>>>
>>> The high bit is the sign extension of bit39.
>>>
>> Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
>> they all indicate that the guessed range should be "likely free" -- 
>> that implies "usable". Given the common VM allocation behavior, we 
>> want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the VA 
>> so it's "likely free".
>>
>> So IMO the point is, will there be any LoongArch HW in the 
>> foreseeable future, with less than maybe 40 bits of VA? If the answer 
>> is "no" then a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling would be 
>> appropriate. Otherwise you may have to choose a value near or even 
>> below a 32-bit VA's upper limit: according to the ISA manual Volume 
>> 1, Section 2.1.5, "typical VALEN is in the range of [40, 48]"; also 
>> see Section 5.2.3, RDVA can be as large as 8, so the actual VA space 
>> could theoretically be as narrow as 40-8=32 bits.
>
>
> Yes, I agree with your point of view this is looking for a "likely 
> free" virtual memory space.
>
>
> But if I want to support chips with less than 40-bit virtual 
> addresses, then the value of this macro needs to be set small.
>
> I think setting this value small will increase the probability of 
> virtual address mapping failure.

Not exactly; in case the TYPE_EMPTY_VM_SPACE address happen to be 
occupied, the mmap will still return something else that's nonzero 
(consult mmap's man page for details), and will not just blow the 
process up straight away.

But...

>
> Chips with less than 40-bit virtual address space are small chips for 
> embedded use.
>
> The purpose of pch is to make compilation faster, but I think we 
> rarely compile on embedded systems. So this situation may not be 
> within our consideration.
>
Everything makes more sense with this context. Now put these 
justification into the commit message (after a little bit of rewording 
maybe) and I think we're good to go then ;-)

Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

在 2023/2/22 下午5:35, WANG Xuerui 写道:
> On 2023/2/22 17:30, Lulu Cheng wrote:
>>
>> 在 2023/2/21 下午9:56, WANG Xuerui 写道:
>>> Hi,
>>>
>>> On 2023/2/21 21:03, Lulu Cheng wrote:
>>>>
>>>> 在 2023/2/21 下午3:41, Xi Ruoyao 写道:
>>>>> On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
>>>>>> Like la264 only has 40 effective bits of virtual address space.
>>>>> I'm OK with the change.  But the VA length is configurable 
>>>>> building the
>>>>> kernel.  Is there any specific reason LA264 has to use the 40-bit
>>>>> configuration, or should we reword the commit message like "for
>>>>> supporting the configuration with less page table level or smaller 
>>>>> page
>>>>> size"?
>>>>
>>>> I consulted with my colleagues who are working on the kernel,
>>>>
>>>> it looks like this:
>>>>
>>>> The la264 chip desgn is physically 40-bit virtual address.
>>>>
>>>> User mode and kernel mode each account for half:
>>>>
>>>> User mode :    0x0-0x7f ffff ffff
>>>>
>>>> Kernel mode:  0xffff ff80 0000 0000 -0xffff ffff ffff ffff
>>>>
>>>> The high bit is the sign extension of bit39.
>>>>
>>> Looking at the comments around the TRY_EMPTY_VM_SPACE definitions, 
>>> they all indicate that the guessed range should be "likely free" -- 
>>> that implies "usable". Given the common VM allocation behavior, we 
>>> want TRY_EMPTY_VM_SPACE to point at a reasonably high place in the 
>>> VA so it's "likely free".
>>>
>>> So IMO the point is, will there be any LoongArch HW in the 
>>> foreseeable future, with less than maybe 40 bits of VA? If the 
>>> answer is "no" then a TRY_EMPTY_VM_SPACE near the 40-bit VA ceiling 
>>> would be appropriate. Otherwise you may have to choose a value near 
>>> or even below a 32-bit VA's upper limit: according to the ISA manual 
>>> Volume 1, Section 2.1.5, "typical VALEN is in the range of [40, 
>>> 48]"; also see Section 5.2.3, RDVA can be as large as 8, so the 
>>> actual VA space could theoretically be as narrow as 40-8=32 bits.
>>
>>
>> Yes, I agree with your point of view this is looking for a "likely 
>> free" virtual memory space.
>>
>>
>> But if I want to support chips with less than 40-bit virtual 
>> addresses, then the value of this macro needs to be set small.
>>
>> I think setting this value small will increase the probability of 
>> virtual address mapping failure.
>
> Not exactly; in case the TYPE_EMPTY_VM_SPACE address happen to be 
> occupied, the mmap will still return something else that's nonzero 
> (consult mmap's man page for details), and will not just blow the 
> process up straight away.
>
> But...
>
>>
>> Chips with less than 40-bit virtual address space are small chips for 
>> embedded use.
>>
>> The purpose of pch is to make compilation faster, but I think we 
>> rarely compile on embedded systems. So this situation may not be 
>> within our consideration.
>>
> Everything makes more sense with this context. Now put these 
> justification into the commit message (after a little bit of rewording 
> maybe) and I think we're good to go then ;-)
OK! Thanks!:-)