Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1958653ybh; Fri, 24 Jul 2020 00:21:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/vMhX4Y9hhjsUekxJsqWeJq7nWQ7AagqKzOXL5tRLy4Ao+5wAr0U4OOIZZyaHAyAW+1Cz X-Received: by 2002:aa7:c6d3:: with SMTP id b19mr7400265eds.207.1595575278170; Fri, 24 Jul 2020 00:21:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595575278; cv=none; d=google.com; s=arc-20160816; b=KMCBzeEbCG1mQ0kQBsI5kf+BFO5j8EMuyo6dW/mVvQiKWmW97DrnHuSgIqtPJPjiHs EFH/188TEqgZsmueZHgt1Sl/pEhlcdDipkMHYHNTOLMGoB3zi1IDoLp6me1tVCdOc1Uu yHDvfUpi5nE+ins+btfAEEkEOqx00zCv/MPJk17By/WsGsp7qtdC5JZX75t1cHm/rTxA Rtw9wFoNGlKenON3sqObn7l3LvghyOGnL1pUNNVUm8VD0VdvvMPLokDEs6qXhi49YA0t VOpOZ7WESTLuYX0vwf/GgU8cmGpx1dr+E0AcxviK803jWv7qaJ8A3f20OxRaJfBOQW/5 NiLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=14OrDpVTf1eswh1YKrTUBJeDStQAndr4stanIUCkJPM=; b=jy6icJ+FocUalbyJvIAJPhdVcdPrs9tb0hm1zPiYZUGhiiZFZv2OjvaNDyt4tihPaA xf/T90Igv0n1zxBcx3az+tTvlIinGrNHJ57Dw1DUo86Veh+Q4zDPpx2rdNGrLLa9NR4G b6GksTyocVM1SNGXf/qA39XNOy/0/J7KqyQ+mwL9ZMW5lnV0OpPbvrE6Y67vb/igIQtS UC0XW9GeH/4BfVNGq+THAVKwoY3FZTYenOzsiZUdMAOTv3c1SJrlzHTNGz+l0QUxv8Kt 1MXp2AA3KaoKXoYlBTG/dKqA4R412ycXh7hLly/1sQKF12/p83OxuJPkGqcMT78Q4S9T mS5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si37609eds.15.2020.07.24.00.20.56; Fri, 24 Jul 2020 00:21:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726835AbgGXHUp (ORCPT + 99 others); Fri, 24 Jul 2020 03:20:45 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:45293 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726572AbgGXHUp (ORCPT ); Fri, 24 Jul 2020 03:20:45 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MjjGV-1keHEv2wmp-00lBo2 for ; Fri, 24 Jul 2020 09:20:42 +0200 Received: by mail-qt1-f171.google.com with SMTP id t23so3149267qto.3 for ; Fri, 24 Jul 2020 00:20:42 -0700 (PDT) X-Gm-Message-State: AOAM530SuF7OG5XqMfg6GPpaYbF5q46RH1mT0E0GSteu2NH74iM3qB+N iWSyCo+GeZOwFaBxdjis+5M28VZmfusqDhGu4e4= 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:4RxKmOPWc9H9BLSFLVfdf0UfPQUj6IMmf++wlXBiilqiu6BgDbp k42jkriobOIuL+51rooxxuB+q6jzOeCiFJf/LcyZ6ORD/rlw6P0heIhL+L/MAl//rVRqx4A w4VZofKyhsebEzEvwumKMYDH4ksDyradhOXaxaOAxlphb38B13v9gEOM1nriup/ArXpRYF8 2YsXtYKIyg6bxPLYOiUMg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2xAHuEgwJFI=:rfCHtkHsWokaz4xcBIPZQy OZUzWD5xEs7YaQT3R+DJLkoFZRZ+R8HjY6crXeSNBLDBPyXCfkW+yGxP/UWg8z9UVcg7n7bA0 DXfjhp2U6RyE/YsQOoCB+P35cdZQldjtJOxrSXV6ipzTP+yuVhzCQB9VK0c8QUpxDrnGeueiR ezG4owhdxVtkAq3L+KcQFcWAxsMfbDMY/pwBeEL9MC0eOKIgeV9NJYCy54Kl5pLCqdS3t1ucu JdccXirMi/CI5dFP1VAmMGIqP70srVikM4myxxk3UDVtGbSfc6ypX4nsCtQAXXE1pn8EX0pAO CxO1zyj3uLN2+R06OcqpG2LbapWroIDaNh0Wip73n1oZ8t/LoErvreX++hUWV9MKi9n8vMDsj ZGwvvO8dUcqmffQxDSYmgIt1K5d5v4EHSQ7r86t81uVfOGS6kULmojkkSVqygsymQXOEMtJOk 7E3rEjVkXVbkC7uE26f2zskWrgHEoQmZEl1X5hgGi8ltwDc7lNGLhW5nQBN0iM6YcqH9emT8H 6qQfs/f3D0loAomPtzUZ6FeucmgO6XHLU9ol8DM5yfXY+Yqan8G+wvpYfvVSCh5gATZ2rYEW+ rKLapG5M3FESQS0wFSxTgCQK/DtRFm0tGoYr6iAYqVzkxFmaKySDNceyaXPmMwKXDnNMLh3Hx IDEUs/FlI3EWHCfWDEZq7GaZIHIz3JqogtlFyGI6HWSZ0tRxvbDTfklmE8SlOLaUe/+rdmVRc 38rLHq79CFNfxCMr8731gBxR5bQenX+feVJG5gPD159A9DpoPKJ/fCiPZtQdkZq1fYze0Tx84 47Eg1eHEztfVfzEnTtyvAbRI5gBib4PDt8g2LNQoVxFG6uyox3I9+Pz7DGvviAJ2ln+IYRr6F YgaaX9pS2wQSVtRkgb24qiTY916Q8O6G6HCpshReijiEY+OyXFAmVxPTmeLP/KYTn/qP2U+fV 94Vajy67VckXwljRzIgYmUpZsJslxP9wLuHlNYxGbtLLYeJzi3/gv Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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