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 7CBB7C433E1 for ; Fri, 24 Jul 2020 07:20:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4768B2065E for ; Fri, 24 Jul 2020 07:20:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4768B2065E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF8148D0005; Fri, 24 Jul 2020 03:20:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA7DF8D0002; Fri, 24 Jul 2020 03:20:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B701F8D0005; Fri, 24 Jul 2020 03:20:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id 9FB158D0002 for ; Fri, 24 Jul 2020 03:20:45 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5850E1730863 for ; Fri, 24 Jul 2020 07:20:45 +0000 (UTC) X-FDA: 77072122050.02.rest99_2c1711226f45 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 33C93100973B9 for ; Fri, 24 Jul 2020 07:20:45 +0000 (UTC) X-HE-Tag: rest99_2c1711226f45 X-Filterd-Recvd-Size: 5866 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jul 2020 07:20:44 +0000 (UTC) Received: from mail-qt1-f174.google.com ([209.85.160.174]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MEFnP-1k959r3B4P-00AAxd for ; Fri, 24 Jul 2020 09:20:42 +0200 Received: by mail-qt1-f174.google.com with SMTP id s16so6254332qtn.7 for ; Fri, 24 Jul 2020 00:20:42 -0700 (PDT) X-Gm-Message-State: AOAM533n40QbvmCTiAE04v9CIqzQCDJN/8IAFP8xR+WEDiJqtbvVW+RP NY40D2DX9azv6kwOasI+zq5qQlVs9iN6QrWSmUM= 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 Cc: Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Atish Patra , Benjamin Herrenschmidt , Anup Patel , "linux-kernel@vger.kernel.org" , Paul Walmsley , Linux-MM , Paul Mackerras , Zong Li , Michael Ellerman , linux-riscv , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:f/TH2589sGjjFcO9elziU+Fx8ua1xdlNhgKabbDhc2sszPzGCPZ 44CEGpE2AQc+GHkwXBAZe3HcbfLSejtBjaTcUrxhxG0wZrFLwVM/nCLIMBi+uTLRYK5LNIZ XS3woNyXLTKJgEBmE4pf2ihLuthZAHTGPTqMwAkJ1Us7y4wAKfeW04W1LMKfXKrfGrfwF0u cubPN00KurVDSG/wIfGBQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:VtAwOLuAkI0=:S6yaEoEEmBJBiNYD/cx6iX rugGKdIq4TEzh1X8jeUr07b/d2RvHStrSv01nYtP4in7dzWGmq4QCCR3qH67Hx3SxTkK7nmcU RBP3zs0kh77PrLD2g3ED4funp4lCB30p2gnqUFTbqY/Nc0XPRPLQjuClT77A5IMIa6K2lJL5z eb+tBGITkvJzyvAwhaL8Lj4OPg9gEkRA2J85EGwVtoC30m2+GanaiS6CIE/xY7b2AU8x5qcOE krFQofJ3ZWVxvxP1mFrgppJT1JXXqotang2rO893OTnSXLGiIlw+pYnRqSjuW/pft48FKr7+O 49rQ2cb/KspqM/vEqG7CsWvm2pwaCjok3dMsbZlNdJtjaUNr2R9IlRq9kd4c0E5jiJqJo2Pe5 PKvn39fi/KXKJbLMcW5m3pkCM7Ae1CqgLKIHXoS1F9K4RJVAHZiiNJc6BBH6eZkDME+dxrUYD +LbE8fQ15FBbRgrpzO1JyRo03buWVXjUp1l36gV76z/pFJ3Bxiy7PawFlrFPHlXo4zM7cbpb8 QsIwDQAzdn2xSCr90t2jHN2UL56Sf58v7jJp793MyQo2j7WB17pIuyyJkYf8jRX1dLT+dPCLG CMU2T40hKT3nV7dh5ftSmtmE2N4dVprgcCVFsL38Mcyzsa1aFe8gDj2TU50iJAyvH2hk3+UrO UGhc3wZeC1RIBBOb6WpD/48ZJJO4+G6S3pbWcUsZA9cxbKipOvB24QjszfKUgCjJzXfudXR05 BG952K1bCeKlIlpA2m1rIGbSWsWMo/CBzsG1CMDtA0Pdou8hvI/OXLlZE71mvkXP4zx94g/XC PMaQ3o2SKfh497XUHaT8JFx0HGS5dmUfPnhkx6E6Bc6V2SOXXBiqisWAvHVUYem9N6XZEZi X-Rspamd-Queue-Id: 33C93100973B9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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