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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 27FB9C43331 for ; Thu, 2 Apr 2020 09:31:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 030CB2073B for ; Thu, 2 Apr 2020 09:31:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387843AbgDBJb4 (ORCPT ); Thu, 2 Apr 2020 05:31:56 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:41445 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725965AbgDBJb4 (ORCPT ); Thu, 2 Apr 2020 05:31:56 -0400 Received: from mail-qt1-f177.google.com ([209.85.160.177]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MlO9r-1iuClr41qn-00lpBO for ; Thu, 02 Apr 2020 11:31:55 +0200 Received: by mail-qt1-f177.google.com with SMTP id t17so2614184qtn.12 for ; Thu, 02 Apr 2020 02:31:54 -0700 (PDT) X-Gm-Message-State: AGi0PuZWrPDQm8FP6TAVP9EDtII0P2MN4xMOyeio7uQXE7oJs0Zf1vc6 F6WmXD48cLJ2/g2BqCMrgxCbWDyr8PK0/0giSWc= X-Google-Smtp-Source: APiQypIyue+WNACvV18x6JnZkYlMs/gOnvsaV2sZZDOWo0BguT88H770dmf7hJplDaKl5fSsfEZ3gDVMPZpGGw8NTyc= X-Received: by 2002:ac8:7292:: with SMTP id v18mr1898092qto.304.1585819913839; Thu, 02 Apr 2020 02:31:53 -0700 (PDT) MIME-Version: 1.0 References: <20200331093241.3728-1-tesheng@andestech.com> In-Reply-To: <20200331093241.3728-1-tesheng@andestech.com> From: Arnd Bergmann Date: Thu, 2 Apr 2020 11:31:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V To: Eric Lin Cc: linux-riscv@lists.infradead.org, Albert Ou , Gary Guo , alex@ghiti.fr, David Abdurachmanov , Steven Price , Anup Patel , "linux-kernel@vger.kernel.org" , Mike Rapoport , atish.patra@wdc.com, yash.shah@sifive.com, Palmer Dabbelt , Greentime Hu , zong.li@sifive.com, Paul Walmsley , Andrew Morton , Borislav Petkov , Logan Gunthorpe , Thomas Gleixner Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:mZH8CricPUBuTLMEoGKz3luhD0XBZqzmZPaec3uE5Oo1LZLiu9D nCes7BdOdjX+e4OPEKf6KJnl1GOMTQWYpTNxnTm7e2XtWAdpnk3Qge0D5jy17NzlI5A7ErB 0DZe1ugkS5xHJdYyo7whtWwsJb0P2sRLo3xtJ42HTUNedx200T1rjTuzjh6B6K6GvRLe93K Jey3pyfWYCxxbcUy/IdLQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:UFvhvFuRUEE=:xw+s9AXkz80ZpQ1r/k1Xc7 /gFz7NzfkWyb8X/hs4CYFW/8Sf4WKLQ7cvI9lhIcML19pgr/1xW6mgngfEkkfzZcedPeeU/2S kdpb3P2IDwB4Ukt/pA9PSLgLzfBJom56etCNtoM9Z/uAILL+VZRll1q8ZP1xepEL2droxQn8I jzVYrCjTg0RqfNKQFfqLJgXfU7E4Me3ZDpgIYHv2eI5TRPrZKW5qiZAsn94OnKSgij5kd43Ft aJ/S1H+JzBEqRF+DTESUzRetyEnsl3oXCHF3iplqAuujv4FUYbK7w9rUAoAuNukkwVefiAfGd a25eZzMtWI1wW/p6tkWm8HuPO97ANj6rYxBIgZlkFnMcj1H60EfAFx45eeYdXcAIorij5JIXN XQawJDhBTC9hW3GRl//0gFKNa4yOIgdzDgk1CzT1NIklw3Stt/E1UUI6x4UVWq27zjL6KrX57 VvIHJKvpQy9seVy/UKS8nePKxtAVZbeoOC0Vxg/pDf3eaBk4xptWAL0pv4YXh0lDGYc7m11Ss i/oSjKRsqXgs+h9if94OkJPGhEN5oRdgA0ocSVBbiGMLT1LRnEn/Lydu/le8U5aM0/cfNgFys 9QyXE1ETyGbGv2vxCoXQs+4aJF49I9i/A9o0wdnyTEstLzEc+SqD6FJZe25c+vWaZ9h+ZihDM 96vDehiyngFz2iBHugjjVe14QTIie9j9+fxcjGG3GptYxQzDRWYzYxlA/fETfSB4/SG46oOQI Z6r8mAoAFHtvw6qrsBPIw1iQ6NorWFEDpV6bticRli0mN+qG/+VGsq/1mMOfYGAgrfburGbyG Adaelst6Wt7j0L2LwGoANwNB06b/bUC645myozAHpRYtlvJkSc= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2020 at 11:34 AM Eric Lin wrote: > > With Highmem support, the kernel can map more than 1GB physical memory. > > This patchset implements Highmem for RV32, referencing to mostly nds32 > and others like arm and mips, and it has been tested on Andes A25MP platform. I would much prefer to not see highmem added to new architectures at all if possible, see https://lwn.net/Articles/813201/ for some background. For the arm32 architecture, we are thinking about implementing a VMPLIT_4G_4G option to replace highmem in the long run. The most likely way this would turn out at the moment looks like: - have a 256MB region for vmalloc space at the top of the 4GB address space, containing vmlinux, module, mmio mappings and vmalloc allocations - have 3.75GB starting at address zero for either user space or the linear map. - reserve one address space ID for kernel mappings to avoid tlb flushes during normal context switches - On any kernel entry, switch the page table to the one with the linear mapping, and back to the user page table before returning to user space - add a generic copy_from_user/copy_to_user implementation based on get_user_pages() in asm-generic/uaccess.h, using memcpy() to copy from/to the page in the linear map. - possible have architectures override get_user/put_user to use a cheaper access based on a page table switch to read individual words if that is cheaper than get_user_pages(). There was an implementation of this for x86 a long time ago, but it never got merged, mainly because there were no ASIDs on x86 at the time and the TLB flushing during context switch were really expensive. As far as I can tell, all of the modern embedded cores do have ASIDs, and unlike x86, most do not support more than 4GB of physical RAM, so this scheme can work to replace highmem in most of the remaining cases, and provide additional benefits (larger user address range, higher separate of kernel/user addresses) at a relatively small performance cost. Arnd 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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D85B5C43331 for ; Thu, 2 Apr 2020 09:32:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 AEC112073B for ; Thu, 2 Apr 2020 09:32:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cVGmEaSb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEC112073B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:To: Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jyLGy4wIa9YpfvGIOZu1h8jBq1vT93tHHQe1KR3dfrU=; b=cVGmEaSbHhkwAwcHLMIp5QMf7 /V1W8sRPS6Qk5eH/yoTSDYtQjRQfqtdmujkj9u2GxlA90afh5CP6pAiTddj5XBrw0wc1FycX0EVKv la8LJQazhkgTI+omyGDo05QAIzS86qR8ari6RCHN8NLnIdoaanTeSr2qODSjjIciWo2adEAeofdME vADEa1FD8zfcIXzfBIlV2zd1ZplfS265zi9C3qCJk4jVJqtVe/Ix0A8k95isi6LEBtygIVV8Ty4+F tw0oQLfXwG+C/NvnhsqOcI1ptQMzlXgrK8gjy7O+PCSr97PV7O/7pv+hRYiaV1l/4oa6ywcfp0C47 UuW/N5f4A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJwCe-0003Nj-Sf; Thu, 02 Apr 2020 09:32:00 +0000 Received: from mout.kundenserver.de ([212.227.126.134]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJwCb-0003My-Ee for linux-riscv@lists.infradead.org; Thu, 02 Apr 2020 09:31:59 +0000 Received: from mail-qt1-f174.google.com ([209.85.160.174]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1Mo7Bb-1j0EeP3szr-00pfqw for ; Thu, 02 Apr 2020 11:31:55 +0200 Received: by mail-qt1-f174.google.com with SMTP id 14so2417580qtp.1 for ; Thu, 02 Apr 2020 02:31:54 -0700 (PDT) X-Gm-Message-State: AGi0PuY30XEfisa0KLOPpASlKihs9FtOj4+05UZGar1qpqTj8Pr9/yWs 6DB5649QfSrpJq6QmEdth3wat48J0wSu7cSVgBI= X-Google-Smtp-Source: APiQypIyue+WNACvV18x6JnZkYlMs/gOnvsaV2sZZDOWo0BguT88H770dmf7hJplDaKl5fSsfEZ3gDVMPZpGGw8NTyc= X-Received: by 2002:ac8:7292:: with SMTP id v18mr1898092qto.304.1585819913839; Thu, 02 Apr 2020 02:31:53 -0700 (PDT) MIME-Version: 1.0 References: <20200331093241.3728-1-tesheng@andestech.com> In-Reply-To: <20200331093241.3728-1-tesheng@andestech.com> From: Arnd Bergmann Date: Thu, 2 Apr 2020 11:31:37 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V To: Eric Lin Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:oHisjB768uoO6+hM3A7PqzK3LDT6mGufBYYAJ3TqTg2eXdnp1hJ CWRku+d36P1NhGARQu8iMIhQODHqVBo/stOUau/LEEKBfu7oAlqAJ0RjUqNKTGv5/UNKetY uyZgutnTqF2BfmkQIPwr86M3x1yYhBr/Uqs38sltWQpZNX0QlIXZYnOGgQUtzcri7dm9lcp QvTCBA+IxMoWyVlZAo9JA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ztG0u1FNqFE=:UC+Lvwq1nCJcdwafSfPIx8 RrGRDLwhGj9i6qGAqEoWfOh8jQEiW0VsGe0nJVhwzDQMt6LAJZtJgVgdM63olLB8u8xl9sw2A NdrKSSOgYvljetP6gFiwCqrw+kn0ZyHjhjR1/gn93RRTdL0+nrj0Fp3k3UZqRDvvoMxns4cSx M8cEpCaNuIkqVsJDUf0ZC0OejLSxi2GudT4I030fv74vvu9dXax8O/wAAWypKOuwUKD4y5RC0 KlN0LdeZK1QpmvWbsXkEMJG0kkXSZurHXbo8js3rA9ey3Kto06Vm3kttDdXwFkoPvenvmI9lx QKfeCra0o3f4WEiO3okUN9pQwXvvOpJbKLNtq09PdB8JlNUasdjfgo98tXUe1cGYhqc5LvYiJ EHbJWGv5hK27KeiVAKGPQv8uatOJ/LhVTWWs/L4OVWGPod8JUPXBjnQ224aGE+5AX5sLN5CN3 RFJn0sZf8gPyMTc7vfD4yfBZkOLjQducoue5ettH2Wi9tD3T5BODvB0keQK4rVepgtuYZlYwE OIHmshLe1Fvo5Cl323f0xWtYaHl7UR24QOc0yZAgbGkrcVhoNluEIwUbtzNn7mDpET0abYc8i FkKA+JjFotvYv+7b80hzLAOtLaLlg4NCazH1O9UHh/bTQgKjXX5wQ51sJCaUVMnJGpkIMUoim L8r/DGQ86G0nNchTTGHPuI/oCvGpNdtZ4RxEtYpWn+DFi9MHkfG7fm+wE2JJNa89VgOWoJEDn 29X6eytnooCMUlAZtOqK+gpUO2qGGCFns74iFp3R/IK7/ZcBZvLowS5j0rocRiwHQSwNPt9jr hgmZ3AOCKR/EI4WAnNJoBdOJP1YfFo7f/sxNk8me+X3EJtyBxo= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200402_023157_781509_977A128D X-CRM114-Status: GOOD ( 13.31 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Borislav Petkov , Albert Ou , Thomas Gleixner , zong.li@sifive.com, alex@ghiti.fr, David Abdurachmanov , Anup Patel , "linux-kernel@vger.kernel.org" , Steven Price , atish.patra@wdc.com, yash.shah@sifive.com, Palmer Dabbelt , Greentime Hu , Gary Guo , Paul Walmsley , linux-riscv@lists.infradead.org, Mike Rapoport , Logan Gunthorpe , Andrew Morton Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Mar 31, 2020 at 11:34 AM Eric Lin wrote: > > With Highmem support, the kernel can map more than 1GB physical memory. > > This patchset implements Highmem for RV32, referencing to mostly nds32 > and others like arm and mips, and it has been tested on Andes A25MP platform. I would much prefer to not see highmem added to new architectures at all if possible, see https://lwn.net/Articles/813201/ for some background. For the arm32 architecture, we are thinking about implementing a VMPLIT_4G_4G option to replace highmem in the long run. The most likely way this would turn out at the moment looks like: - have a 256MB region for vmalloc space at the top of the 4GB address space, containing vmlinux, module, mmio mappings and vmalloc allocations - have 3.75GB starting at address zero for either user space or the linear map. - reserve one address space ID for kernel mappings to avoid tlb flushes during normal context switches - On any kernel entry, switch the page table to the one with the linear mapping, and back to the user page table before returning to user space - add a generic copy_from_user/copy_to_user implementation based on get_user_pages() in asm-generic/uaccess.h, using memcpy() to copy from/to the page in the linear map. - possible have architectures override get_user/put_user to use a cheaper access based on a page table switch to read individual words if that is cheaper than get_user_pages(). There was an implementation of this for x86 a long time ago, but it never got merged, mainly because there were no ASIDs on x86 at the time and the TLB flushing during context switch were really expensive. As far as I can tell, all of the modern embedded cores do have ASIDs, and unlike x86, most do not support more than 4GB of physical RAM, so this scheme can work to replace highmem in most of the remaining cases, and provide additional benefits (larger user address range, higher separate of kernel/user addresses) at a relatively small performance cost. Arnd