public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: WANG Xuerui <i@xen0n.name>
To: Lulu Cheng <chenglulu@loongson.cn>,
	Xi Ruoyao <xry111@xry111.site>,
	gcc-patches@gcc.gnu.org, pinskia@gcc.gnu.org,
	richard.sandiford@arm.com
Cc: xuchenghua@loongson.cn
Subject: Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.
Date: Tue, 21 Feb 2023 21:56:58 +0800	[thread overview]
Message-ID: <afb30b13-68de-69d9-e863-4bf13c21c103@xen0n.name> (raw)
In-Reply-To: <b110118d-84f2-030c-c6ce-58c5b682076f@loongson.cn>

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.


  reply	other threads:[~2023-02-21 13:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  7:20 Lulu Cheng
2023-02-21  7:41 ` Xi Ruoyao
2023-02-21 13:03   ` Lulu Cheng
2023-02-21 13:56     ` WANG Xuerui [this message]
2023-02-22  9:30       ` Lulu Cheng
2023-02-22  9:35         ` WANG Xuerui
2023-02-22  9:49           ` Lulu Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afb30b13-68de-69d9-e863-4bf13c21c103@xen0n.name \
    --to=i@xen0n.name \
    --cc=chenglulu@loongson.cn \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=pinskia@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    --cc=xry111@xry111.site \
    --cc=xuchenghua@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).