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 CECABC433E5 for ; Fri, 24 Jul 2020 08:14:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7DA3820748 for ; Fri, 24 Jul 2020 08:14:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DA3820748 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 A4B6B8D002B; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FAAA8D0027; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EA448D002B; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 7A0A08D0027 for ; Fri, 24 Jul 2020 04:14:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E5810180397BE for ; Fri, 24 Jul 2020 08:14:46 +0000 (UTC) X-FDA: 77072258172.05.kick62_480764326f45 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id B856C1811E9C9 for ; Fri, 24 Jul 2020 08:14:46 +0000 (UTC) X-HE-Tag: kick62_480764326f45 X-Filterd-Recvd-Size: 5304 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Jul 2020 08:14:45 +0000 (UTC) Received: from mail-qt1-f171.google.com ([209.85.160.171]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MTRdK-1kOHSC1sEu-00TlnM for ; Fri, 24 Jul 2020 10:14:44 +0200 Received: by mail-qt1-f171.google.com with SMTP id k18so6309744qtm.10 for ; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) X-Gm-Message-State: AOAM533kTokKgT088+hnAlEEi7DseFnqINXVomBhnmwhMuDKVcm/8r4b x7NM5W4uS4uyiGisottirIR23Mj45Pz1EvxgX3I= X-Google-Smtp-Source: ABdhPJygisjtG0/T5RZOpGU5w2vxR1Ybi3XIk/oHG1gnkzduo22/qOY0PE84/zvIhSqmrnDmSiaO0gHwgOoBfMX/5hA= X-Received: by 2002:ac8:7587:: with SMTP id s7mr8295990qtq.304.1595578483047; Fri, 24 Jul 2020 01:14:43 -0700 (PDT) MIME-Version: 1.0 References: <7cb2285e-68ba-6827-5e61-e33a4b65ac03@ghiti.fr> <54af168083aee9dbda1b531227521a26b77ba2c8.camel@kernel.crashing.org> <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> In-Reply-To: <418d5f3d3f42bbc79c5cf30e18ec89edfe2dbd26.camel@kernel.crashing.org> From: Arnd Bergmann Date: Fri, 24 Jul 2020 10:14:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone To: Benjamin Herrenschmidt Cc: Alex Ghiti , Palmer Dabbelt , Albert Ou , 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:ah0NcL+ATEYgZ0AAHAueqRr2v/CvmpDm88b3hIuvT6ouFmeL3/2 0NkxeSnYgPQeoKh9mlJEnc7zFA9KrOCtZIh3i4k5LTT7K8+m1kfyalOw/UfX4xI5hYRz7Fg XIb9xgXJFzaEwLLlhPRS2qFYHCH8dio0DFqGzbZk2Jr6h1lVIsWxqRmLOG+wBduCn07oMgC 5JrrnHh5485Hu7Eob2nbg== X-UI-Out-Filterresults: notjunk:1;V03:K0:17bBDCa767U=:n3PwViPQKW8aJFM52GXLAc mf/r48Ne9AUSygLXDCs58qtO/F6VR+YR+veIseA8/U0MMrcv/8Zp4a7wUVqr9jZLCV1Ji8ZEk g8darHv45kta3liN1WTadx5QTUGCp8puZlrRpbFmnCUeawl+pSwzcS7N2/DmNExfgEfHtgUGN Ay5mPsuFP/Vx7HLdBiZdYeYWSiYdG/cpJShkhfXL4QeogeVMFBZ73dv58kIW4Lg98KSHOjuVw xBW+MN8eE8PFKBQ/kWF431BhEPRjV7J/m4p/GHqYQZkNlzlC5jgdLEPZE0UHPwpy1xpetmXL8 OBHgtQuPzpHxcjhsRt4U9ZjPjd5iuSlUYdikZpjPZGi4xA4mTeigElMuN83jB63EKRSdaqniC +LImRFP6ogBOahdq50VhoPgGBWETbBI1roE4pWYAw70w8VTdOIqXPiYDJKHojCfC9zs59IZZh J56cTgArAgIPZ4sUIlt724AX/hOsQvuHuj/F6a6gentsY9EQ9aDzIkOMbfxMeUWFaeIFwzfFb ESJFT7d/aDMd1524/orDxTm+qAqj2ZOVm/C6E1M4rnbCjDzlzy56iuw94AclMdFF9ofw4iOlz 3eNlarCc1o1y4v5UFhxjmb6hDtt5ClJe1G8BmGjGSY9nsXpD6EaNCGsekNLdmSU0G+GlHnR6k FXasPYE0TInc/c+cVFx5MG3reag3ELHaLmKODs3tMgJU7s96Xo22/tpOzAKXZxrvTFrLVSmTM sLU0pz8C9iSH4wxmk0ei4jAmXCVxCFZkXrVp6ehM/getFt2d/GDnS0xhElODgkb97x047kIfB SVaLXOlb1pXu/5rPE9UVkTGIINY96LWHdbNha3AciaO+7Pjj8Yt9KuIK3NuQFiP1u89G/669W jYcYqMxQMbNERe5UVbBESc0TbgsOQgyPhwN9KpLy71u+ZsTWIFatRNcSzx0qEV+ifNoxCdETT /+jsEMi8T9SqISC062pLP+LdarbYhFS1B13xuW/3LAFgDj4kB4wox X-Rspamd-Queue-Id: B856C1811E9C9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Fri, Jul 24, 2020 at 12:34 AM Benjamin Herrenschmidt wrote: > On Thu, 2020-07-23 at 01:21 -0400, Alex Ghiti wrote: > > > works fine with huge pages, what is your problem there ? You rely on > > > punching small-page size holes in there ? > > > > > > > ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel > > mapping in the direct mapping as it sets different permissions to > > different part of the kernel (data, text..etc). > > Ah ok, that can be solved in a couple of ways... > > One is to use the linker script to ensure those sections are linked > HUGE_PAGE_SIZE appart and moved appropriately by early boot code. One > is to selectively degrade just those huge pages. > > I'm not familiar with the RiscV MMU (I should probably go have a look) > but if it's a classic radix tree with huge pages at PUD/PMD level, then > you could just degrade the one(s) that cross those boundaries. That would work, but if the system can otherwise use 1GB-sized pages, that might mean degrading the first gigabyte into a mix of 2MB pages and 4KB pages. If the kernel is in vmalloc space and vmap is able to use 2MB pages for contiguous chunks of the mapping, you get a somewhat better TLB usage. However, this also means that a writable mapping exists in the linear mapping for any executable part of the kernel (.text in both vmlinux and modules). Do we have that on other architectures as well, or is this something that ought to be prevented with STRICT_KERNEL_RWX/STRICT_MODULE_RWX? Arnd