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 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 48769C433E0 for ; Wed, 22 Jul 2020 20:22:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 13F2420684 for ; Wed, 22 Jul 2020 20:22:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13F2420684 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 759086B0002; Wed, 22 Jul 2020 16:22:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70A846B0005; Wed, 22 Jul 2020 16:22:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F8116B0006; Wed, 22 Jul 2020 16:22:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 4A5656B0002 for ; Wed, 22 Jul 2020 16:22:46 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C3DA210A7E26D for ; Wed, 22 Jul 2020 20:22:45 +0000 (UTC) X-FDA: 77066835090.03.toes43_110257626f38 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 9886D14391 for ; Wed, 22 Jul 2020 20:22:45 +0000 (UTC) X-HE-Tag: toes43_110257626f38 X-Filterd-Recvd-Size: 5027 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jul 2020 20:22:44 +0000 (UTC) Received: from mail-qt1-f179.google.com ([209.85.160.179]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MWBC8-1kIklV15Ug-00XdiP for ; Wed, 22 Jul 2020 22:22:43 +0200 Received: by mail-qt1-f179.google.com with SMTP id w9so2836869qts.6 for ; Wed, 22 Jul 2020 13:22:42 -0700 (PDT) X-Gm-Message-State: AOAM5332pqyz/TX1S+7kX5HxvNxWeeT6q9ir263S/qAi9JohBlNZmMAm JCf7dxd+MkFm0bEbGtaXxFITtcRlt+wJ11NZoBE= X-Google-Smtp-Source: ABdhPJzomOuvyv87HLrmnRqLMg+xagc+vFRLOHIlCjUhIO6Ps1D+MblDa1Ac6NHH61/GfVpqpoR58oXKvv+qOpTZNZk= X-Received: by 2002:ac8:6743:: with SMTP id n3mr1132159qtp.7.1595449361849; Wed, 22 Jul 2020 13:22:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Arnd Bergmann Date: Wed, 22 Jul 2020 22:22:25 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Palmer Dabbelt Cc: Alexandre Ghiti , Albert Ou , Benjamin Herrenschmidt , Linux-MM , Michael Ellerman , Anup Patel , "linux-kernel@vger.kernel.org" , Atish Patra , Paul Mackerras , Zong Li , Paul Walmsley , linux-riscv , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:m/Clw5vOHf9Gjgkisbe7drGsqPn0Lkmyzo8tstGXzI/gV45y+6K 9U4raGWSYJzrueBxCDmyCS1KZGSdSTtZ6HGyk3RJ+xqUTnBbYLJ12CmuO0rVbiDTyWYcPmo qhv3iRDm4MReCWeglsr+zrk1lbYif/BLqrQxrAAGq53q0xCG4GusMuL1slctqM9yS5lI5F6 UDuUE98gUyKFBtVd/A1Kg== X-UI-Out-Filterresults: notjunk:1;V03:K0:eaaNHJNozp4=:3zh4evzvd1gfmmuZnQHcM7 5qVSHQgPg337XD4bvrYwRBg22n4InNT1rq3cQXM6spaNXJgIhXohE+0ZuMmUIS9iANs1ZBNwR BUZv6QyXlXdLPZIgYbvK6WraYQ/i3hOI3Gu/4oHuhkWJsLKfsa3moq0tm7+Qn3SIRyIBP2cqy WukN5CyQXNFvJkUuCxhF3NglaGCdlt3o8BxTJbj6kjfEgRVekGzt+lXIRPPTS0NF2ATG09CAM RgTtCs0Kw0z0o3Y5VF8jEBDjepKzMHi3aM+JbhrmjCaaj3ZxptytCwrYQVYXnf+kkLc9ishZ7 Gfr3blzbinMB8ijgtgCBxH/XD8b737RAcdpTBEfNkURo1/9phqPsv51hraKqjth3mTgwVaCH2 uvUXuXTGPEQBaQc4MeszoL4Tl08V3Zeecx1z3ho4MG6qVNVSIYhrOuvUwRIa7lzJfyCx8By1u 5CrFKDzF5V6mVvaiAneqSxFIpDyujxrEiz7CkomCGXDTGYEMPYf5rV/u2lVQpSwa/NPXdqPZn agIZmOfV0lglb8padyeTRNsSiL4pdWcLOU0SzgRBt3Ba+uSyg5oIQF8zx1I1S5FzzSLZAE+8A PbInmxKB0AGadovf5I+C/7AR5oqEVi6fIpc3XskIjG2dXmfxatMl8k5/AxiPP1qpofMdAbvI5 6BhPQDf4GQ5MoKMENs34ba1e145M68OK8bIklahQRbvSt+RdMQG/K6tb2vrooP8EiUaxjvHt9 K2qO/ZroXMeuX1yKWSqMjX+DDj04ljoqzAPsigTNKhdfK8q+d3+Qw+Y+BLTgXvKXRqmN+csRF w3axmVv5ejvEc//hQuDUVJWW0XjtU1HB6OU2NjdDn/Yo+w1lzwVFIXJISuV+tPNcdlwV4WJbA 8jxXM2m76PRvDI2jXkaWLdY6Skcuwit8wd9p491fxK1PtFdsEnCoUlJM9Z3jz9LguAvccyPOY s1ebahOHONqzLblVc12bYffFt6Kl4iLbQ1KZISRIVUuHrp5ubCB3h X-Rspamd-Queue-Id: 9886D14391 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 9:52 PM Palmer Dabbelt wrote: > On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote: > > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt wrote: > > The eventual goal is to have a split of 3840MB for either user or linear map > > plus and 256MB for vmalloc, including the kernel. Switching between linear > > and user has a noticeable runtime overhead, but it relaxes both the limits > > for user memory and lowmem, and it provides a somewhat stronger > > address space isolation. > > Ya, I think we decided not to do that, at least for now. I guess the right > answer there will depend on what 32-bit systems look like, and since we don't > have any I'm inclined to just stick to the fast option. Makes sense. Actually on 32-bit Arm we see fewer large-memory configurations in new machines than we had in the past before 64-bit machines were widely available at low cost, so I expect not to see a lot new hardware with more than 1GB of DDR3 (two 256Mbit x16 chips) for cost reasons, and rv32 is likely going to be similar, so you may never really see a need for highmem or the above hack to increase the size of the linear mapping. 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. Arnd