[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZO532zzLXSKvpvb0@casper.infradead.org>
Date: Tue, 29 Aug 2023 23:57:31 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Guo Ren <guoren@...nel.org>, linux-mm@...ck.org,
mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] MM updates for 6.6-rc1
On Tue, Aug 29, 2023 at 02:31:38PM -0700, Linus Torvalds wrote:
> On Mon, 28 Aug 2023 at 18:43, Andrew Morton <akpm@...ux-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.
Powered by blists - more mailing lists