linux-kernel - Re: [GIT PULL] MM updates for 6.6-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJF2gTQXXMwmSZnWkBgyCS6XYDStgpw4aF5N--Rj-R=tHgfhtA@mail.gmail.com>
Date:   Wed, 30 Aug 2023 09:33:35 +0800
From:   Guo Ren <guoren@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>, 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 Wed, Aug 30, 2023 at 6:57 AM Matthew Wilcox <willy@...radead.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@...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.

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.

-- 
Best Regards
 Guo Ren