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 804C93858D33; Wed, 22 Feb 2023 09:50:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 804C93858D33 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 _____8Axz_9H5fVj94kDAA--.1727S3; Wed, 22 Feb 2023 17:49:59 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Axvr5G5fVjPqc4AA--.43030S2; Wed, 22 Feb 2023 17:49:59 +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> <6333af35-1490-6d03-b385-22b6f41abe49@loongson.cn> From: Lulu Cheng Message-ID: <4c9b91fd-2c99-42fc-b442-e2ce86a69697@loongson.cn> Date: Wed, 22 Feb 2023 17:49:58 +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:AQAAf8Axvr5G5fVjPqc4AA--.43030S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxGF4xAw4UtF1DKF4fJFW8WFg_yoW5Aw4fpF y5Xa1IkF4kJryay3yvy3ZI9F1jy39xtw4UXrn8Jryruwn0kFy29r15Jr13uF9rZr4kCw12 qr4kKFW7Z3WYyFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU baxYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS 0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc02F40EFcxC0V AKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42 xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxVAFwI0_JF0_Jw1l x2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14 v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IY x2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87 Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZF pf9x07jUsqXUUUUU= 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/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!:-)