Message ID | 20230828184251.bfbc164280503903eacf498c@linux-foundation.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] MM updates for 6.6-rc1 | expand |
On Mon, 28 Aug 2023 at 18:43, Andrew Morton <akpm@linux-foundation.org> wrote: > > csky tree, arch/csky/abiv2/cacheflush.c: > https://lkml.kernel.org/r/20230815104604.54f65293@canb.auug.org.au At least this resolution in linux-next was wrong. It would just keep on doing a cache invalidate on the same one-page address range over and over again. I think I did it right, but obviously can't test (and am too lazy to build-test too). Of course, it won't actually matter unless you have large folio on csky, which is probably hard to impossible to trigger in practice, but I thought I'd mention it if for no other reason than Guo Ren to be aware and at least test-build and maybe think about it. Linus
The pull request you sent on Mon, 28 Aug 2023 18:42:51 -0700:
> https://lkml.kernel.org/r/20230725094013.2dfb0168@canb.auug.org.au and
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b96a3e9142fdf346b05b20e867b4f0dfca119e96
Thank you!
On Tue, Aug 29, 2023 at 02:31:38PM -0700, Linus Torvalds wrote: > On Mon, 28 Aug 2023 at 18:43, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > csky tree, arch/csky/abiv2/cacheflush.c: > > https://lkml.kernel.org/r/20230815104604.54f65293@canb.auug.org.au > > At least this resolution in linux-next was wrong. It would just keep > on doing a cache invalidate on the same one-page address range over > and over again. > > I think I did it right, but obviously can't test (and am too lazy to > build-test too). > > Of course, it won't actually matter unless you have large folio on > csky, which is probably hard to impossible to trigger in practice, but > I thought I'd mention it if for no other reason than Guo Ren to be > aware and at least test-build and maybe think about it. As far as I can tell, csky doesn't enable support for HUGETLBFS nor for TRANSPARENT_HUGEPAGE and large folios are currently disabled unless you have TRANSPARENT_HUGEPAGE, simply because they rely on infrastructure that's only built for TRANSPARENT_HUGEPAGE. We should probably fix that at some point; allocating in larger chunks is beneficial even if you don't have PMD sized TLB entries. But the motivation to do that work has been lacking; there are plenty of more important projects in the queue.
On Wed, Aug 30, 2023 at 6:57 AM Matthew Wilcox <willy@infradead.org> wrote: > > On Tue, Aug 29, 2023 at 02:31:38PM -0700, Linus Torvalds wrote: > > On Mon, 28 Aug 2023 at 18:43, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > csky tree, arch/csky/abiv2/cacheflush.c: > > > https://lkml.kernel.org/r/20230815104604.54f65293@canb.auug.org.au > > > > At least this resolution in linux-next was wrong. It would just keep > > on doing a cache invalidate on the same one-page address range over > > and over again. > > > > I think I did it right, but obviously can't test (and am too lazy to > > build-test too). > > > > Of course, it won't actually matter unless you have large folio on > > csky, which is probably hard to impossible to trigger in practice, but > > I thought I'd mention it if for no other reason than Guo Ren to be > > aware and at least test-build and maybe think about it. > > As far as I can tell, csky doesn't enable support for HUGETLBFS nor for > TRANSPARENT_HUGEPAGE and large folios are currently disabled unless you > have TRANSPARENT_HUGEPAGE, simply because they rely on infrastructure > that's only built for TRANSPARENT_HUGEPAGE. We should probably fix that > at some point; allocating in larger chunks is beneficial even if you don't > have PMD sized TLB entries. But the motivation to do that work has been > lacking; there are plenty of more important projects in the queue. Yes, csky (a 32-bit architecture) doesn't have the plan to support HUGEPAGE. So, below only gets one loop and is no different from before, right? + for (i = 0; i < folio_nr_pages(folio); i++) { Next, I would test more after folio feature merged.