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=-0.8 required=3.0 tests=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 A5223C3F2C6 for ; Wed, 11 Mar 2020 14:54:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 48DB820734 for ; Wed, 11 Mar 2020 14:54:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 48DB820734 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 29CD76B0003; Wed, 11 Mar 2020 10:29:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2740B6B0007; Wed, 11 Mar 2020 10:29:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18B696B0008; Wed, 11 Mar 2020 10:29:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id F23496B0003 for ; Wed, 11 Mar 2020 10:29:11 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C5B92181AEF1F for ; Wed, 11 Mar 2020 14:29:11 +0000 (UTC) X-FDA: 76583313702.06.goat21_8a6a59e2b5020 X-HE-Tag: goat21_8a6a59e2b5020 X-Filterd-Recvd-Size: 4836 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Mar 2020 14:29:11 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3CF0F31B; Wed, 11 Mar 2020 07:29:10 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.71]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AEA6A3F67D; Wed, 11 Mar 2020 07:29:07 -0700 (PDT) Date: Wed, 11 Mar 2020 14:29:05 +0000 From: Catalin Marinas To: Arnd Bergmann Cc: Russell King - ARM Linux admin , Nishanth Menon , Santosh Shilimkar , Tero Kristo , Linux ARM , Michal Hocko , Rik van Riel , Santosh Shilimkar , Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Roman Gushchin Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Message-ID: <20200311142905.GI3216816@arrakis.emea.arm.com> References: <20200212085004.GL25745@shell.armlinux.org.uk> <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> <7c4c1459-60d5-24c8-6eb9-da299ead99ea@oracle.com> <20200306203439.peytghdqragjfhdx@kahuna> <20200309155945.GA4124965@arrakis.emea.arm.com> <20200309160919.GM25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Mar 09, 2020 at 08:46:18PM +0100, Arnd Bergmann wrote: > On Mon, Mar 9, 2020 at 5:09 PM Russell King - ARM Linux admin > wrote: > > On Mon, Mar 09, 2020 at 03:59:45PM +0000, Catalin Marinas wrote: > > > On Sun, Mar 08, 2020 at 11:58:52AM +0100, Arnd Bergmann wrote: > > > > - revisit CONFIG_VMSPLIT_4G_4G for arm32 (and maybe mips32) > > > > to see if it can be done, and what the overhead is. This is probably > > > > more work than the others combined, but also the most promising > > > > as it allows the most user address space and physical ram to be used. > > > > > > A rough outline of such support (and likely to miss some corner cases): > > > > > > 1. Kernel runs with its own ASID and non-global page tables. > > > > > > 2. Trampoline code on exception entry/exit to handle the TTBR0 switching > > > between user and kernel. > > > > > > 3. uaccess routines need to be reworked to pin the user pages in memory > > > (get_user_pages()) and access them via the kernel address space. > > > > > > Point 3 is probably the ugliest and it would introduce a noticeable > > > slowdown in certain syscalls. > > There are probably a number of ways to do the basic design. The idea > I had (again, probably missing more corner cases than either of you > two that actually understand the details of the mmu): > > - Assuming we have LPAE, run the kernel vmlinux and modules inside > the vmalloc space, in the top 256MB or 512MB on TTBR1 > > - Map all the physical RAM (up to 3.75GB) into a reserved ASID > with TTBR0 > > - Flip TTBR0 on kernel entry/exit, and again during user access. > > This is probably more work to implement than your idea, but > I would hope this has a lower overhead on most microarchitectures > as it doesn't require pinning the pages. Depending on the > microarchitecture, I'd hope the overhead would be comparable > to that of ARM64_SW_TTBR0_PAN. This still doesn't solve the copy_{from,to}_user() case where both address spaces need to be available during copy. So you either pin the user pages in memory and access them via the kernel mapping or you temporarily map (kmap?) the destination/source kernel address. The overhead I'd expect to be significantly greater than ARM64_SW_TTBR0_PAN for the uaccess routines. For user entry/exit, your suggestion is probably comparable with SW PAN. -- Catalin