From: Catalin Marinas <catalin.marinas@arm.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de>, Nishanth Menon <nm@ti.com>, Santosh Shilimkar <santosh.shilimkar@oracle.com>, Tero Kristo <t-kristo@ti.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Michal Hocko <mhocko@suse.com>, Rik van Riel <riel@surriel.com>, Santosh Shilimkar <ssantosh@kernel.org>, Dave Chinner <david@fromorbit.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, Yafang Shao <laoar.shao@gmail.com>, Al Viro <viro@zeniv.linux.org.uk>, Johannes Weiner <hannes@cmpxchg.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, kernel-team@fb.com, Kishon Vijay Abraham I <kishon@ti.com>, Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Roman Gushchin <guro@fb.com> Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Date: Mon, 9 Mar 2020 16:57:49 +0000 [thread overview] Message-ID: <20200309165749.GB4124965@arrakis.emea.arm.com> (raw) In-Reply-To: <20200309160919.GM25745@shell.armlinux.org.uk> On Mon, Mar 09, 2020 at 04:09:19PM +0000, Russell King 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. > > We also need to consider that it has implications for the single-kernel > support; a kernel doing this kind of switching would likely be horrid > for a kernel supporting v6+ with VIPT aliasing caches. Good point. I think with VIPT aliasing cache uaccess would have to flush the cache before/after access, depending on direction. > Would we be adding a new red line between kernels supporting > VIPT-aliasing caches (present in earlier v6 implementations) and > kernels using this system? get_user_pages() should handle the flush_dcache_page() call and the latter would dial with the aliases. But this adds heavily to the cost of the uaccess. Maybe some trick with temporarily locking the user page table and copying the user pmd into a dedicated kernel pmd, then accessing the user via this location. The fault handler would need to figure out the real user address and I'm not sure how we deal with the page table lock (or mmap_sem). An alternative to the above would be to have all uaccess routines in a trampoline which restores the user pgd but with only a couple of pmds for mapping the kernel address temporarily. This would avoid the issue of concurrent modification of the user page tables. Anyway, I don't think any of the above looks better than highmem. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Russell King - ARM Linux admin <linux@armlinux.org.uk> Cc: Nishanth Menon <nm@ti.com>, Michal Hocko <mhocko@suse.com>, Arnd Bergmann <arnd@arndb.de>, Rik van Riel <riel@surriel.com>, Roman Gushchin <guro@fb.com>, Santosh Shilimkar <santosh.shilimkar@oracle.com>, Dave Chinner <david@fromorbit.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Kishon Vijay Abraham I <kishon@ti.com>, Tero Kristo <t-kristo@ti.com>, Linux-MM <linux-mm@kvack.org>, Yafang Shao <laoar.shao@gmail.com>, Johannes Weiner <hannes@cmpxchg.org>, Al Viro <viro@zeniv.linux.org.uk>, Santosh Shilimkar <ssantosh@kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, kernel-team@fb.com, Linus Torvalds <torvalds@linux-foundation.org>, Andrew Morton <akpm@linux-foundation.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Date: Mon, 9 Mar 2020 16:57:49 +0000 [thread overview] Message-ID: <20200309165749.GB4124965@arrakis.emea.arm.com> (raw) In-Reply-To: <20200309160919.GM25745@shell.armlinux.org.uk> On Mon, Mar 09, 2020 at 04:09:19PM +0000, Russell King 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. > > We also need to consider that it has implications for the single-kernel > support; a kernel doing this kind of switching would likely be horrid > for a kernel supporting v6+ with VIPT aliasing caches. Good point. I think with VIPT aliasing cache uaccess would have to flush the cache before/after access, depending on direction. > Would we be adding a new red line between kernels supporting > VIPT-aliasing caches (present in earlier v6 implementations) and > kernels using this system? get_user_pages() should handle the flush_dcache_page() call and the latter would dial with the aliases. But this adds heavily to the cost of the uaccess. Maybe some trick with temporarily locking the user page table and copying the user pmd into a dedicated kernel pmd, then accessing the user via this location. The fault handler would need to figure out the real user address and I'm not sure how we deal with the page table lock (or mmap_sem). An alternative to the above would be to have all uaccess routines in a trampoline which restores the user pgd but with only a couple of pmds for mapping the kernel address temporarily. This would avoid the issue of concurrent modification of the user page tables. Anyway, I don't think any of the above looks better than highmem. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-09 16:57 UTC|newest] Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-11 17:55 [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Johannes Weiner 2020-02-11 18:20 ` Johannes Weiner 2020-02-11 19:05 ` Rik van Riel 2020-02-11 19:05 ` Rik van Riel 2020-02-11 19:31 ` Johannes Weiner 2020-02-11 23:44 ` Andrew Morton 2020-02-12 0:28 ` Linus Torvalds 2020-02-12 0:28 ` Linus Torvalds 2020-02-12 0:47 ` Andrew Morton 2020-02-12 1:03 ` Linus Torvalds 2020-02-12 1:03 ` Linus Torvalds 2020-02-12 1:03 ` Linus Torvalds 2020-02-12 8:50 ` Russell King - ARM Linux admin 2020-02-12 8:50 ` Russell King - ARM Linux admin 2020-02-13 9:50 ` Lucas Stach 2020-02-13 9:50 ` Lucas Stach 2020-02-13 9:50 ` Lucas Stach 2020-02-13 16:52 ` Arnd Bergmann 2020-02-13 16:52 ` Arnd Bergmann 2020-02-13 16:52 ` Arnd Bergmann 2020-02-15 11:25 ` Geert Uytterhoeven 2020-02-15 11:25 ` [cip-dev] " Geert Uytterhoeven 2020-02-15 11:25 ` Geert Uytterhoeven 2020-02-15 11:25 ` Geert Uytterhoeven 2020-02-15 16:59 ` Arnd Bergmann 2020-02-15 16:59 ` [cip-dev] " Arnd Bergmann 2020-02-15 16:59 ` Arnd Bergmann 2020-02-15 16:59 ` Arnd Bergmann 2020-02-16 9:44 ` Geert Uytterhoeven 2020-02-16 9:44 ` [cip-dev] " Geert Uytterhoeven 2020-02-16 9:44 ` Geert Uytterhoeven 2020-02-16 9:44 ` Geert Uytterhoeven 2020-02-16 19:54 ` Chris Paterson 2020-02-16 19:54 ` [cip-dev] " Chris Paterson 2020-02-16 19:54 ` Chris Paterson 2020-02-16 20:38 ` Arnd Bergmann 2020-02-16 20:38 ` [cip-dev] " Arnd Bergmann 2020-02-16 20:38 ` Arnd Bergmann 2020-02-16 20:38 ` Arnd Bergmann 2020-02-20 14:35 ` Chris Paterson 2020-02-20 14:35 ` [cip-dev] " Chris Paterson 2020-02-20 14:35 ` Chris Paterson 2020-02-26 18:04 ` santosh.shilimkar 2020-02-26 18:04 ` santosh.shilimkar 2020-02-26 21:01 ` Arnd Bergmann 2020-02-26 21:01 ` Arnd Bergmann 2020-02-26 21:01 ` Arnd Bergmann 2020-02-26 21:11 ` santosh.shilimkar 2020-02-26 21:11 ` santosh.shilimkar 2020-03-06 20:34 ` Nishanth Menon 2020-03-06 20:34 ` Nishanth Menon 2020-03-07 1:08 ` santosh.shilimkar 2020-03-07 1:08 ` santosh.shilimkar 2020-03-08 10:58 ` Arnd Bergmann 2020-03-08 10:58 ` Arnd Bergmann 2020-03-08 10:58 ` Arnd Bergmann 2020-03-08 14:19 ` Russell King - ARM Linux admin 2020-03-08 14:19 ` Russell King - ARM Linux admin 2020-03-09 13:33 ` Arnd Bergmann 2020-03-09 13:33 ` Arnd Bergmann 2020-03-09 13:33 ` Arnd Bergmann 2020-03-09 14:04 ` Russell King - ARM Linux admin 2020-03-09 14:04 ` Russell King - ARM Linux admin 2020-03-09 15:04 ` Arnd Bergmann 2020-03-09 15:04 ` Arnd Bergmann 2020-03-09 15:04 ` Arnd Bergmann 2020-03-10 9:16 ` Michal Hocko 2020-03-10 9:16 ` Michal Hocko 2020-03-09 15:59 ` Catalin Marinas 2020-03-09 15:59 ` Catalin Marinas 2020-03-09 16:09 ` Russell King - ARM Linux admin 2020-03-09 16:09 ` Russell King - ARM Linux admin 2020-03-09 16:57 ` Catalin Marinas [this message] 2020-03-09 16:57 ` Catalin Marinas 2020-03-09 19:46 ` Arnd Bergmann 2020-03-09 19:46 ` Arnd Bergmann 2020-03-09 19:46 ` Arnd Bergmann 2020-03-11 14:29 ` Catalin Marinas 2020-03-11 14:29 ` Catalin Marinas 2020-03-11 16:59 ` Arnd Bergmann 2020-03-11 16:59 ` Arnd Bergmann 2020-03-11 16:59 ` Arnd Bergmann 2020-03-11 17:26 ` Catalin Marinas 2020-03-11 17:26 ` Catalin Marinas 2020-03-11 22:21 ` Arnd Bergmann 2020-03-11 22:21 ` Arnd Bergmann 2020-03-11 22:21 ` Arnd Bergmann 2020-02-12 3:58 ` Matthew Wilcox 2020-02-12 8:09 ` Michal Hocko 2020-02-17 13:31 ` Pavel Machek 2020-02-12 16:35 ` Johannes Weiner 2020-02-12 18:26 ` Andrew Morton 2020-02-12 18:52 ` Johannes Weiner 2020-02-12 12:25 ` Yafang Shao 2020-02-12 12:25 ` Yafang Shao 2020-02-12 16:42 ` Johannes Weiner 2020-02-13 1:47 ` Yafang Shao 2020-02-13 1:47 ` Yafang Shao 2020-02-13 13:46 ` Johannes Weiner 2020-02-14 2:02 ` Yafang Shao 2020-02-14 2:02 ` Yafang Shao 2020-02-13 18:34 ` [PATCH v2] " Johannes Weiner 2020-02-14 16:53 ` [PATCH] " kbuild test robot 2020-02-14 16:53 ` kbuild test robot 2020-02-14 21:30 ` kbuild test robot 2020-02-14 21:30 ` kbuild test robot 2020-02-14 21:30 ` [PATCH] vfs: fix boolreturn.cocci warnings kbuild test robot 2020-02-14 21:30 ` kbuild test robot 2020-05-12 21:29 ` [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Johannes Weiner 2020-05-13 1:32 ` Yafang Shao 2020-05-13 1:32 ` Yafang Shao 2020-05-13 13:00 ` Johannes Weiner 2020-05-13 21:15 ` Andrew Morton 2020-05-14 11:27 ` Johannes Weiner 2020-05-14 2:24 ` Andrew Morton 2020-05-14 10:37 ` Johannes Weiner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200309165749.GB4124965@arrakis.emea.arm.com \ --to=catalin.marinas@arm.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=david@fromorbit.com \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=kernel-team@fb.com \ --cc=kishon@ti.com \ --cc=laoar.shao@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ --cc=mhocko@suse.com \ --cc=nm@ti.com \ --cc=riel@surriel.com \ --cc=santosh.shilimkar@oracle.com \ --cc=ssantosh@kernel.org \ --cc=t-kristo@ti.com \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.