From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1FC5EC433E0 for ; Fri, 24 Jul 2020 07:23:09 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB52D2065E for ; Fri, 24 Jul 2020 07:23:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB52D2065E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4BCgf23m4HzDsZ0 for ; Fri, 24 Jul 2020 17:23:06 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=212.227.126.131; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4BCgbP64MrzDrqV for ; Fri, 24 Jul 2020 17:20:48 +1000 (AEST) Received: from mail-qt1-f176.google.com ([209.85.160.176]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mq2vS-1kbpTF2Z50-00n5m6 for ; Fri, 24 Jul 2020 09:20:43 +0200 Received: by mail-qt1-f176.google.com with SMTP id a32so6262829qtb.5 for ; Fri, 24 Jul 2020 00:20:42 -0700 (PDT) X-Gm-Message-State: AOAM531KnalDnwQbVIHqI7fGjc0l9zu5ImhW5DBIRPAnjC8vZc6K/KZO 7T5+h1ATSDLmsjDuEhRGteMljeR4mGSnW+RsMBc= X-Google-Smtp-Source: ABdhPJxmIVXnbEioXbPXSA7ZMWes4VKvilueIEtCY7yjI+BhfVsAWHUQWo3DE1p/ihdJ0qb68PSFrNOEs1zZFP+V6+8= X-Received: by 2002:ac8:688e:: with SMTP id m14mr1188191qtq.7.1595575241528; Fri, 24 Jul 2020 00:20:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Fri, 24 Jul 2020 09:20:25 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Atish Patra Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:rtlTBXJAnM/9MwfGED8/vkYCYN5xxO0C5BFsrnc0GfvBXz216gD 2JWMoQUiQsDIf0H2EqT7jTDs2prGuK8pOJF8OIHDEkQq6v/JJ1ZpBHCvsGD2919FcUZybYb lXLP1aoDu/NXg6LzwT0mt5Ihx8DTSWu4nNK0R+ULv99BuZrhEJlM8vle2GHCMzETHlClZNe NEA6KTH7/LL0lybVPkNxw== X-UI-Out-Filterresults: notjunk:1;V03:K0:0YfiYEKXuSo=:iHBUm5UO1sZmc+wgfp2OdX cS4AeyliiuFjaw/B1p6lzj5YgYPnJRpHZ2VCw+VoeHUUfDsnTH6SGiU5B3NSqs41ZI2bG7J18 G5F03Op+F1zwIqIngGMMjYT+vXMO4tAHyPIitxmrAjIr1WlEVbO9X86S/gznj0NXhx9a/Dz0y E5fDl1OSY9Ctgi64CexomukCwBRbck/vOmlQWwtUDTDVTNuFBfhk217xi3gcyGFZeYDzhDjnE AjzUSUobWu6Qe6rJ7jt4joY2Pz+S3zCM7Zaw0Dgvkwla8qlUQ302jdKK+6oz7kJseuTGfyi0M nFOOJOoc01WCaGO+K6VITVAyWyX9Kvq4Efu2PSxjEe8rZacM2fRIKAOzzy1bZVTQSLm3QslQP SS486obGiKPAPwwvBmZWvUa6t3Q3RjODThGRJ6OkAlBSzhJ6+UPPE3zLFM/S0V63lmXCh+Fuh DyCkLql+h8Kc5s8Fp2HRRGVcMJebPpMsz8p4SlawY5mA2wfEJayzQLemm1g+SgQ8remXpB3oj S2i/sZv2J9Si7N+ClvQdbiq+Zn3JVUpLk+7tvejebdwiSSXjg7hmhX/f6Tvu52wPRTKkzquC7 eW9wl+Cs3cIxKRapeyiJC0s+PRqnBXCRCxciBfDdDrPn1280BqnPB5oL9cRYKcw8CnFqv8rx0 Jtkc2iplHIw5ylduNXDMIWQzTyjtcfPZzfpfkY060yjRyE0+ERA8eMW40TnYBCNIcmxBKcGlf ds/sEqb4SWvPYBDcUl9At+vsE7RnM4R84KXdrp2IY7wUa3KcvTCUowLsC6SjxWlH3tZorVhXL nOK7OpYitPjSTNWped15F1wjq+lfOxzoeD1c70Q1L3ijYqM/spnIdD43pSGRmjh5mix/9JdRp zzTuSPIoe+/cYXuiBRf7a48dyY4hWbbSosickRqxPiaRdpWQexX3Z4TGeFEzU5EOhu2rpfiUH Gh2JVfw6ObwNpBIXZvMwdLuK/KT4R0fmlw29oS+2FUSyTn6BcEXI2 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Albert Ou , Alexandre Ghiti , Linux-MM , Anup Patel , "linux-kernel@vger.kernel.org" , Atish Patra , Palmer Dabbelt , Zong Li , Paul Walmsley , Paul Mackerras , linux-riscv , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jul 22, 2020 at 11:06 PM Atish Patra wrote: > > On Wed, Jul 22, 2020 at 1:23 PM Arnd Bergmann wrote: > > > > I just noticed that rv32 allows 2GB of lowmem rather than just the usual > > 768MB or 1GB, at the expense of addressable user memory. This seems > > like an unusual choice, but I also don't see any reason to change this > > or make it more flexible unless actual users appear. > > > > I am a bit confused here. As per my understanding, RV32 supports 1GB > of lowmem only > as the page offset is set to 0xC0000000. The config option > MAXPHYSMEM_2GB is misleading > as RV32 actually allows 1GB of physical memory only. Ok, in that case I was apparently misled by the Kconfig option name. I just tried building a kernel to see what the boundaries actually are, as this is not the only confusing bit. Here is what I see: 0x9dc00000 TASK_SIZE/FIXADDR_START /* code comment says 0x9fc00000 */ 0x9e000000 FIXADDR_TOP/PCI_IO_START 0x9f000000 PCI_IO_END/VMEMMAP_START 0xa0000000 VMEMMAP_END/VMALLOC_START 0xc0000000 VMALLOC_END/PAGE_OFFSET Having exactly 1GB of linear map does make a lot of sense. Having PCI I/O, vmemmap and fixmap come out of the user range means you get slightly different behavior in user space if there are any changes to that set, but that is probably fine as well, if you want the flexibility to go to a 2GB linear map and expect user space to deal with that as well. There is one common trick from arm32 however that you might want to consider: if vmalloc was moved above the linear map rather than below, the size of the vmalloc area can dynamically depend on the amount of RAM that is actually present rather than be set to a fixed value. On arm32, there is around 240MB of vmalloc space if the linear map is fully populated with RAM, but it can grow to use all of the avaialable address space if less RAM was detected at boot time (up to 3GB depending on CONFIG_VMSPLIT). > Any memory blocks beyond > DRAM + 1GB are removed in setup_bootmem. IMHO, The current config > should clarify that. > > Moreover, we should add 2G split under a separate configuration if we > want to support that. Right. It's probably not needed immediately, but can't hurt either. Arnd