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=-2.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 2B5EAC433E1 for ; Thu, 14 May 2020 13:35:54 +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 0241D20727 for ; Thu, 14 May 2020 13:35:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Kl/f/5xR"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QMSW1I6g" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0241D20727 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=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: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=E9W1sJQt/AkGPQv8yrPnHpGoqDsCP8Uvp/Cdxi7xlfQ=; b=Kl/f/5xRRctjCf SUDku4sPSTRDoVf91s7zVYLO7VBgMlLEVo/2MVJRuIrAY31J3NE1HP2lY/4y8oz6n7O9Py5lmn7To mBxaFDV2S2R8OYUpFXoJ4/HFk3rlzVt30YNmPX7PuIa4y3PqjMQ8glIBiqiN7aQ+I1oclAtdp6OFH jLVVYj/9zttWSd1cxMzO1dlMX5yFE30G2hnq1bCeJpxNB/z0f/VoINIiFND43xJiWmKlt+jTkOPF4 kT14nMKQOaqWHxGgqqZ8gYpVQQpSIykJd6a/YPo0QiUOhiAefaEBsDW5UqswkHyMgig+H2gI5NkR+ yyBnw9IMJ4iR1uxLOwbg==; 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 1jZE1h-0007aD-FO; Thu, 14 May 2020 13:35:53 +0000 Received: from mail-pf1-x443.google.com ([2607:f8b0:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZE1d-0007Zm-Tc for linux-arm-kernel@lists.infradead.org; Thu, 14 May 2020 13:35:51 +0000 Received: by mail-pf1-x443.google.com with SMTP id 23so1315960pfy.8 for ; Thu, 14 May 2020 06:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dFH4YBbehMI5t5iqf9Q3qC3HSqGhIHfBCfuP+cdahd4=; b=QMSW1I6g69BXV603QaMHpeUSgDh97tVPbW+aOr8TNB1DROgfixI7vPwvLqnPQftRbu k/DPWZZCyDkAqkGMyKxaCuU0auNG8u3VNTsYoKg9i/6TfyufPw31JBq/HqrXhlY25q1O FEoyvdlBEbpmE+R9iw2Bk2PDZdoUDuaBcRV4+4KZrgKr2IdlZWue1/hOrdi/XGwFUh+L myzCQVsNAZHA17H/eqiUz6s17fy9GI9NvsMmjq2Mrnegh2/CXKfNxpd76zfde3+2XF4Y 9GlNZqEtCWPbdJmgW+qw8QzMoUZgkAfkbH8Vqoah21hxzL4zQOTpotm6U+rO26/XhNZe cxTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dFH4YBbehMI5t5iqf9Q3qC3HSqGhIHfBCfuP+cdahd4=; b=q4GsKl1NkFuRS9f2CbUHehkVgLyiDttEXTT7mSEvSpGlFbiCYNG8AEKTWZdzqCYx9l Ot+T/a1YuZkGi7ZXqa0pzWLc8ggxhncXoKgA9XB4bm8qQae56YB0nF4N1rzsgF3K8aGe xMGo3ctapodqcWhoEfBIoFmzUkYA10Au7v0cMe1xw+dtBxLfQM1vx2RhOHwiAB+TUmup lwtoyicF+MCOi0Era6Uq3LNkZYEuRJSJ4+s08DZQHHhlhC6CJlIzhe9r/Aw44bjeSpW5 wICoDp5DZDWeS/rXPbaLDX2a+lkLN2Lca1+XwRF56Ly8jryJtsMcZJFvPwjvaLl44+lN B+ew== X-Gm-Message-State: AOAM531CsbZLAHNxvHzikRJJxcE0g4HR+Oj3XfgvcKl+OR0EaqBZVUG3 3PYhQGgztSi0A9Sg3lBQmLc= X-Google-Smtp-Source: ABdhPJyQMSiFyybpBsgKRX8zYbVXbAgjPZ/ufU3iqqpt6IQVzBBGvLrZ288ij1pt0DGhq+h93Zc31g== X-Received: by 2002:a62:ab16:: with SMTP id p22mr4250043pff.216.1589463348447; Thu, 14 May 2020 06:35:48 -0700 (PDT) Received: from localhost ([49.207.51.148]) by smtp.gmail.com with ESMTPSA id gb6sm4426799pjb.56.2020.05.14.06.35.47 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 May 2020 06:35:47 -0700 (PDT) Date: Thu, 14 May 2020 19:05:45 +0530 From: afzal mohammed To: Arnd Bergmann Subject: Re: ARM: static kernel in vmalloc space Message-ID: <20200514133545.GA5020@afzalpc> References: <20200503145017.GA5074@afzalpc> <20200504091018.GA24897@afzalpc> <20200511142113.GA31707@afzalpc> <20200512104758.GA12980@afzalpc> <20200514111755.GA4997@afzalpc> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200514_063549_956075_6DE201B4 X-CRM114-Status: GOOD ( 17.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Russell King , Linux ARM , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote: > On Thu, May 14, 2020 at 1:18 PM afzal mohammed wrote: > > 1. SoC w/ LPAE > > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc, > > kmap, fixmap & vectors > Right, these kind of go together because pre-LPAE cannot do the > same TTBR1 split, and they more frequently have conflicting > static mappings. > > It's clearly possible to do something very similar for older chips > (v6 or v7 without LPAE, possibly even v5), it just gets harder > while providing less benefit. Yes, lets have it only for LPAE > > 3. TTBR0 (low 3768MB) for user space & lowmem (kernel lowmem to have > hardcoded 3840/256 split is likely the best compromise of all the hmm,i swallowed 72MB ;) > > 4. for user space to/from copy > > a. pin user pages > > b. kmap user page (can't corresponding lowmem be used instead ?) > - In the long run, there is no need for kmap()/kmap_atomic() after > highmem gets removed from the kernel, but for the next few years > we should still assume that highmem can be used, in order to support > systems like the 8GB highbank, armadaxp, keystone2 or virtual > machines. For lowmem pages (i.e. all pages when highmem is > disabled), kmap_atomic() falls back to page_address() anyway, > so there is no much overhead. Here i have some confusion - iiuc, VMSPLIT_4G_4G is meant to help platforms having RAM > 768M and <= 4GB disable high memory and still be able to access full RAM, so high memory shouldn't come into picture, right ?. And for the above platforms it can continue current VMPSLIT option (the default 3G/1G), no ?, as VMSPLIT_4G_4G can't help complete 8G to be accessible from lowmem. So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of caveat in Kconfig help that this is meant for platforms w/ <=4GB), then we can do copy_{from,to}_user the same way currently do, and no need to do the user page pinning & kmap, right ? Only problem i see is Kernel compiled w/ VMSPLIT_4G_4G not suitable for >4GB machines, but anyway iiuc, it is was not meant for those machines. And it is not going to affect our current multiplatform setup as LPAE is not defined in multi_v7. Regards afzal _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel