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=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 E6BFBC433DF for ; Wed, 22 Jul 2020 05:46:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9D62207BB for ; Wed, 22 Jul 2020 05:46:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=dabbelt-com.20150623.gappssmtp.com header.i=@dabbelt-com.20150623.gappssmtp.com header.b="fCuEEXu+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9D62207BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 321CA6B0003; Wed, 22 Jul 2020 01:46:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D3436B0005; Wed, 22 Jul 2020 01:46:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EA066B0006; Wed, 22 Jul 2020 01:46:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 089606B0003 for ; Wed, 22 Jul 2020 01:46:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6F0BD9408CE9 for ; Wed, 22 Jul 2020 05:46:41 +0000 (UTC) X-FDA: 77064627402.16.drink70_5c08d6b26f33 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 3F9F418084D27 for ; Wed, 22 Jul 2020 05:46:41 +0000 (UTC) X-HE-Tag: drink70_5c08d6b26f33 X-Filterd-Recvd-Size: 6559 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Jul 2020 05:46:40 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id n5so608308pgf.7 for ; Tue, 21 Jul 2020 22:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=c3WKCCywdgvLGCz57S7am54sr0h7w7V/JrEMUHUMU/o=; b=fCuEEXu++BATZZEgu63jyhgE+Y1XNFfh/hfRTuYGDp7tRoc6LbkGOtZmRlJEX0Q4mc 58Wx5DrHLgqWGA15ODfmp4BD+A6kqkaXmwBVAcQy7tZT4nC6LrgGJ3lzv06Ej9jur88k XGQBpKOytzyljGp9JTo/2ytrZBP2jJniHbB1MwjDRZhque2NwdZ0aWGsgryRqU+3DE9U m+vgwzNJSvheMii7MxNhJxPUYaZbP4XIj428wVkVonkWkFnWlNi3Hd/UlX/sByadTgHP sXR0VV6uQ74NOk6fTFxzR7f22jvf+xzhKswTeZHjL411qPbZeON+M2WgzsdrCjh868sb i6BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=c3WKCCywdgvLGCz57S7am54sr0h7w7V/JrEMUHUMU/o=; b=oZ2WYSjuNcOpBfX+PNsk3mURsi/H9bv4oXXKspide/961gVp6S90jghmLqQe7po82P d7rl/MUFf116PxAimg3EZ7zXePQIX7iDwTcJ41Dw7oLk4TD15tA8nli27Q7IWdXzPSyd jM8dVphCX6XkwF6OYlfCle6I0LU7vTIxsut4G3d8N80AdSW48aIDacz932a9EJBI/HkS X5uBAxExF2hwEbsVy1MxNn5aSmS5BmZnPZwjlz/YntMMFVpFsupenm6cTnzcI5XYnS2R zdOv3EP8NyLkIZxTBgLS7wbJwm9VtxnzZRBTCyFxtHLWhmaaNS7I/mCBVKKNvj1hHU1f 0s9A== X-Gm-Message-State: AOAM533ZhzJor/OYPD9Fo5ivo8fHLmDr0x4iHGzSUJnBzH7cZ39JwHf0 ezAqu+lmU5tATtzBe1W+91fVkA== X-Google-Smtp-Source: ABdhPJwR06FNegYVsAU8o74hwv373Yq9KlDunC4jItd8mIVMPn3zgJSHBlM3MLtzBDjvCEtSQnV5Fg== X-Received: by 2002:a62:7505:: with SMTP id q5mr25490271pfc.262.1595396799507; Tue, 21 Jul 2020 22:46:39 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id r16sm22153983pfh.64.2020.07.21.22.46.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2020 22:46:38 -0700 (PDT) Date: Tue, 21 Jul 2020 22:46:38 -0700 (PDT) X-Google-Original-Date: Tue, 21 Jul 2020 22:46:37 PDT (-0700) Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone In-Reply-To: <87sgdkqhjx.fsf@mpe.ellerman.id.au> CC: benh@kernel.crashing.org, alex@ghiti.fr, paulus@samba.org, Paul Walmsley , aou@eecs.berkeley.edu, Anup Patel , Atish Patra , zong.li@sifive.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-mm@kvack.org From: Palmer Dabbelt To: mpe@ellerman.id.au Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed X-Rspamd-Queue-Id: 3F9F418084D27 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 21 Jul 2020 21:50:42 PDT (-0700), mpe@ellerman.id.au wrote: > Benjamin Herrenschmidt writes: >> On Tue, 2020-07-21 at 16:48 -0700, Palmer Dabbelt wrote: >>> > Why ? Branch distance limits ? You can't use trampolines ? >>> >>> Nothing fundamental, it's just that we don't have a large code model = in the C >>> compiler. As a result all the global symbols are resolved as 32-bit >>> PC-relative accesses. We could fix this with a fast large code model= , but then >>> the kernel would need to relax global symbol references in modules an= d we don't >>> even do that for the simple code models we have now. FWIW, some of t= he >>> proposed large code models are essentially just split-PLT/GOT and the= refor >>> don't require relaxation, but at that point we're essentially PIC unt= il we >>> have more that 2GiB of kernel text -- and even then, we keep all the >>> performance issues. >> >> My memory might be out of date but I *think* we do it on powerpc >> without going to a large code model, but just having the in-kernel >> linker insert trampolines. > > We build modules with the large code model, and always have AFAIK: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /arch/powerpc/Makefile?commit=3D4fa640dc52302b5e62b01b05c755b055549633ae#= n129 > > # -mcmodel=3Dmedium breaks modules because it uses 32bit offsets from > # the TOC pointer to create pointers where possible. Pointers into th= e > # percpu data area are created by this method. > # > # The kernel module loader relocates the percpu data section from the > # original location (starting with 0xd...) to somewhere in the base > # kernel percpu data space (starting with 0xc...). We need a full > # 64bit relocation for this to work, hence -mcmodel=3Dlarge. > KBUILD_CFLAGS_MODULE +=3D -mcmodel=3Dlarge Well, a fast large code model would solve a lot of problems :). Unfortun= ately we just don't have enough people working on this stuff to do that. It's = a somewhat tricky thing to do on RISC-V as there aren't any quick sequences= for long addresses, but I don't think we're that much worse off than everyone= else. At some point I had a bunch of designs written up, but they probably went= along with my SiFive computer. I think we ended up decided that the best bet w= ould be to distribute constant tables throughout the text such that they're accessible via the 32-bit PC-relative loads at any point -- essentially t= he multi-GOT stuff that MIPS used for big objects. Doing that well is a lot= of work and doing it poorly is just as slow as PIC, so we never got around t= o it. > We also insert trampolines for branches, but IIUC that's a separate > issue. "PowerPC branch trampolines" points me here https://sourceware.org/binutils/docs-2.20/ld/PowerPC-ELF32.html . That s= ounds like what we're doing already in the medium code models: we have short an= d medium control transfer sequences, linker relaxation optimizes them when possible. Since we rely on linker relaxation pretty heavily we just don'= t bother with the smaller code model: it'd be a 12-bit address space for da= ta and a 21-bit address space for text (with 13-bit maximum function size). Ins= tead of building out such a small code model we just spent time improving the = linker.