From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id A8A4A3858D33; Wed, 22 Feb 2023 09:31:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8A4A3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.4.52]) by gateway (Coremail) with SMTP id _____8AxJITV4PVjeYgDAA--.1700S3; Wed, 22 Feb 2023 17:31:01 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxF73T4PVj66M4AA--.37770S2; Wed, 22 Feb 2023 17:31:00 +0800 (CST) Subject: Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000. To: WANG Xuerui , Xi Ruoyao , gcc-patches@gcc.gnu.org, pinskia@gcc.gnu.org, richard.sandiford@arm.com Cc: xuchenghua@loongson.cn References: <20230221072001.480858-1-chenglulu@loongson.cn> From: Lulu Cheng Message-ID: <6333af35-1490-6d03-b385-22b6f41abe49@loongson.cn> Date: Wed, 22 Feb 2023 17:30:59 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8CxF73T4PVj66M4AA--.37770S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoW7Cw4fWF4rCry8AryDXF4ktFb_yoW8KryxpF W5XF4xKF4kJryay3ykt3ZIkw4qywsrKw43tw1DGryrCwn0kryj9rn0vF13Za9rZr4kA3Wa qr4vgFW7Aa1YkFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bxAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS 0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc02F40EFcxC0V AKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42 xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWU GwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI4 8JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4U MIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I 8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jUsqXUUUUU= X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 在 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.