Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2042477ybt; Thu, 2 Jul 2020 22:25:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpLOTlzpbgU+TkvowNoaI9UdOaw1Yxim6/ioEHveFBwo9nDzIqxMB6tRxdaWk3DKMgAgvF X-Received: by 2002:a50:aca6:: with SMTP id x35mr37226983edc.328.1593753911823; Thu, 02 Jul 2020 22:25:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593753911; cv=none; d=google.com; s=arc-20160816; b=MJ3YGt0MrFwWumDg21uwIzfNcuGYQC24jLgXIZxcupDaGKuxwGHMHv6ViStFj7thnd 6jlJ/rQvVMqp979VasvtOlI0AX9Z1sa4/xzayybmGbJkiAXcjetBKFtdKvLGOz6aRJUU sjfUGjh5/rCNvKOxJuRi6trwPYyRGMvRQsHDXvlL9T7SznJVbezsppMtnRILGoCJnl21 5ayjsxdWs98ZWZT0fen8Yop/1KGfW9+hExBldzxX+m8kgkuDGmb8S6nRsdPAKcz/KgHY 6qtLXXUUGXHIUx1OFFBqsDSdcZMvI8wQP5vlhURfemL5B9j0DqzX5NVS7mubCqIHsyLe e6vw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=v3S8uff1mzO0KLmI39vYWFb9CvuIWgCeiyX/1xm5qPM=; b=iC3tF5LcAZqHBtW1kebmTTUOe27dTE/VdU/Aq9qKI3ynv2k+6lHe7Te3WqDwn/KPTg i6vOSoThsBhvP7xiL6zrmg2fgDYynTFHVA80eUKfcfoe0Y7L+yMIPQg7iHnPgeQMtaRA flKmiFdvJ7xlhSm0PhluHFNSWQm8/2rNTFJUBTP7nTbV939IvUKVdCyIlDjLYQ4dOjtc e+UN8mo346mAZG6eLuRofWfSSuLGg3eJdfABgbIJUkMOzr53sUBeiqvzgb+4raoTM+Kr hGvs2TqWkayXkfcUdi2nFKw6Wt4GNxwCb7sfMLWrR7mtmmhMZ27B4dSqD80xfAVfn49w BOaw== 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 l5si7167352edq.166.2020.07.02.22.24.49; Thu, 02 Jul 2020 22:25:11 -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 S1725972AbgGCFWi (ORCPT + 99 others); Fri, 3 Jul 2020 01:22:38 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:45091 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725764AbgGCFWi (ORCPT ); Fri, 3 Jul 2020 01:22:38 -0400 X-Originating-IP: 90.112.45.105 Received: from [192.168.1.11] (lfbn-gre-1-325-105.w90-112.abo.wanadoo.fr [90.112.45.105]) (Authenticated sender: alex@ghiti.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 6C99860002; Fri, 3 Jul 2020 05:22:34 +0000 (UTC) From: Alex Ghiti Subject: Re: [PATCH v2 0/8] Introduce sv48 support To: Palmer Dabbelt Cc: Paul Walmsley , zong.li@sifive.com, anup@brainfault.org, Christoph Hellwig , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: Message-ID: <3a3a95ad-dddc-6246-6ec9-bea61f0e1766@ghiti.fr> Date: Fri, 3 Jul 2020 01:22:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Palmer, Le 7/1/20 à 2:27 PM, Palmer Dabbelt a écrit : > On Wed, 03 Jun 2020 01:10:56 PDT (-0700), alex@ghiti.fr wrote: >> This patchset implements sv48 support at runtime. The kernel will try to >> boot with 4-level page table and will fallback to 3-level if the HW >> does not >> support it. >> >> The biggest advantage is that we only have one kernel for 64bit, which >> is way easier to maintain. >> >> Folding the 4th level into a 3-level page table has almost no cost at >> runtime. But as mentioned Palmer, the relocatable code generated is less >> performant. >> >> At the moment, there is no way to build a 3-level page table >> non-relocatable >> 64bit kernel. We agreed that distributions will use this runtime >> configuration >> anyway, but Palmer proposed to introduce a new Kconfig, which I will >> do later >> as sv48 support was asked for 5.8. > > Sorry I wasn't clear last time, but this still has the same fundamental > issue: > it forces 64-bit kernels to be relocatable, which imposes a performance > penalty.  We don't have any hardware that can actually take advantage of > sv48, > so I don't want to take anything that penalizes what people are actually > using > in order to add a feature people can't use. > > I'd be OK taking this if sv48 support simply depended on a relocatable > kernel, > as then users who want the faster kernel could still build one.  I don't > want > to take something that forces all 64-bit kernels to be relocatable. Indeed, I had not understood that this was a requirement. I will add a patch on top of this one introducing a new config, I have to think about it. But even if I understand that the new level of indirection coming with PIE will be slower, is this new config worth it ? Can we benchmark somehow the performance loss ? IMHO I think that this config will get broken over time by lack of testing because I believe distributions will go for KASLR kernel which requires the relocatability property anyway. Alex > >> Finally, the user can now ask for sv39 explicitly by using the >> device-tree >> which will reduce memory footprint and reduce the number of memory >> accesses >> in case of TLB miss. >> >> Changes in v2: >>   * Move variable declarations to pgtable.h in patch 5/7 as suggested >> by Anup >>   * Restore mmu-type properties in patch 6 as suggested by Anup >>   * Fix unused variable in patch 5 that was used in patch 6 >>   * Fix SPARSEMEM build (patch 2 was modified so I dropped the >> Reviewed-by) >>   * Applied various Reviewed-by >> >> Alexandre Ghiti (8): >>   riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE >>   riscv: Allow to dynamically define VA_BITS >>   riscv: Simplify MAXPHYSMEM config >>   riscv: Prepare ptdump for vm layout dynamic addresses >>   riscv: Implement sv48 support >>   riscv: Allow user to downgrade to sv39 when hw supports sv48 >>   riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo >>   riscv: Explicit comment about user virtual address space size >> >>  arch/riscv/Kconfig                  |  34 ++--- >>  arch/riscv/include/asm/csr.h        |   3 +- >>  arch/riscv/include/asm/fixmap.h     |   1 + >>  arch/riscv/include/asm/page.h       |  15 +++ >>  arch/riscv/include/asm/pgalloc.h    |  36 ++++++ >>  arch/riscv/include/asm/pgtable-64.h |  97 +++++++++++++- >>  arch/riscv/include/asm/pgtable.h    |  31 ++++- >>  arch/riscv/include/asm/sparsemem.h  |   6 +- >>  arch/riscv/kernel/cpu.c             |  23 ++-- >>  arch/riscv/kernel/head.S            |   3 +- >>  arch/riscv/mm/context.c             |   2 +- >>  arch/riscv/mm/init.c                | 194 ++++++++++++++++++++++++---- >>  arch/riscv/mm/ptdump.c              |  49 +++++-- >>  13 files changed, 412 insertions(+), 82 deletions(-)