From: Xi Ruoyao <xry111@xry111.site>
To: Lulu Cheng <chenglulu@loongson.cn>,
gcc-patches@gcc.gnu.org, pinskia@gcc.gnu.org,
richard.sandiford@arm.com
Cc: i@xen0n.name, 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 15:41:14 +0800 [thread overview]
Message-ID: <ca044965aa9b8b8a25818583f05302d1de47abe3.camel@xry111.site> (raw)
In-Reply-To: <20230221072001.480858-1-chenglulu@loongson.cn>
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
next prev parent reply other threads:[~2023-02-21 7:41 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 [this message]
2023-02-21 13:03 ` Lulu Cheng
2023-02-21 13:56 ` WANG Xuerui
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=ca044965aa9b8b8a25818583f05302d1de47abe3.camel@xry111.site \
--to=xry111@xry111.site \
--cc=chenglulu@loongson.cn \
--cc=gcc-patches@gcc.gnu.org \
--cc=i@xen0n.name \
--cc=pinskia@gcc.gnu.org \
--cc=richard.sandiford@arm.com \
--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).