Message-ID: <CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgottedy0S6YYeUw@mail.gmail.com>
Date: Wed, 22 Oct 2025 01:24:43 +0800
From: Kairui Song <ryncsn@...il.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: akpm@...ux-foundation.org, hughd@...gle.com, willy@...radead.org, 
	david@...hat.com, lorenzo.stoakes@...cle.com, ziy@...dia.com, 
	Liam.Howlett@...cle.com, npache@...hat.com, ryan.roberts@....com, 
	dev.jain@....com, baohua@...nel.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: shmem: fix the strategy for the tmpfs 'huge=' options

On Wed, Sep 3, 2025 at 4:59 PM Baolin Wang
<baolin.wang@...ux.alibaba.com> wrote:
>
> After commit acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs"),
> we have extended tmpfs to allow any sized large folios, rather than just
> PMD-sized large folios.
>
> The strategy discussed previously was:
> "
> Considering that tmpfs already has the 'huge=' option to control the
> PMD-sized large folios allocation, we can extend the 'huge=' option to
> allow any sized large folios.  The semantics of the 'huge=' mount option
> are:
>
>     huge=never: no any sized large folios
>     huge=always: any sized large folios
>     huge=within_size: like 'always' but respect the i_size
>     huge=advise: like 'always' if requested with madvise()
>
> Note: for tmpfs mmap() faults, due to the lack of a write size hint, still
> allocate the PMD-sized huge folios if huge=always/within_size/advise is
> set.
>
> Moreover, the 'deny' and 'force' testing options controlled by
> '/sys/kernel/mm/transparent_hugepage/shmem_enabled', still retain the same
> semantics.  The 'deny' can disable any sized large folios for tmpfs, while
> the 'force' can enable PMD sized large folios for tmpfs.
> "
>
> This means that when tmpfs is mounted with 'huge=always' or 'huge=within_size',
> tmpfs will allow getting a highest order hint based on the size of write() and
> fallocate() paths. It will then try each allowable large order, rather than
> continually attempting to allocate PMD-sized large folios as before.
>
> However, this might break some user scenarios for those who want to use
> PMD-sized large folios, such as the i915 driver which did not supply a write
> size hint when allocating shmem [1].
>
> Moreover, Hugh also complained that this will cause a regression in userspace
> with 'huge=always' or 'huge=within_size'.
>
> So, let's revisit the strategy for tmpfs large page allocation. A simple fix
> would be to always try PMD-sized large folios first, and if that fails, fall
> back to smaller large folios. This approach differs from the strategy for
> large folio allocation used by other file systems, however, tmpfs is somewhat
> different from other file systems, as quoted from David's opinion:
> "
> There were opinions in the past that tmpfs should just behave like any other fs,
> and I think that's what we tried to satisfy here: use the write size as an
> indication.
>
> I assume there will be workloads where either approach will be beneficial. I also
> assume that workloads that use ordinary fs'es could benefit from the same strategy
> (start with PMD), while others will clearly not.
> "
>
> [1] https://lore.kernel.org/lkml/0d734549d5ed073c80b11601da3abdd5223e1889.1753689802.git.baolin.wang@linux.alibaba.com/
> Fixes: acd7ccb284b8 ("mm: shmem: add large folio support for tmpfs")
> Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
> ---
> Changes from RFC:
>  - Update the commit message.

Hi Baolin

I'm seeing userspace errors after this commit. I'm using
"transparent_hugepage_tmpfs=within_size/always" and build kernel test
on top of tmpfs with swap on ZRAM, both within_size / always
results in same failure:

The error I'm seeing is when build the kernel gcc always fail with:
ld: kernel/workqueue.o:(.data..read_mostly+0x28): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o:(.data..read_mostly+0x20): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o:(.data..read_mostly+0x18): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o:(.data..read_mostly+0x10): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o:(.data..read_mostly+0x8): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o:(.data..read_mostly+0x0): multiple definition
of `no symbol'; kernel/workqueue.o:(.data..read_mostly+0x30): first
defined here
ld: kernel/workqueue.o: in function `no symbol':
:(.text+0x3760): multiple definition of `no symbol';
kernel/workqueue.o:(.data..read_mostly+0x30): first defined here
ld: kernel/workqueue.o: in function `no symbol':
:(.text+0x38c0): multiple definition of `no symbol';
kernel/workqueue.o:(.data..read_mostly+0x30): first defined here
ld: kernel/workqueue.o: in function `no symbol':

... <hundreds of lines of error like this on different files>...

After reverting this commit, the error is gone. I have a very stable
reproduce rate locally with different cgroup / memory pressure with
this patch applied, error logs are basically the same.

I'm still not sure what is causing this, a kernel bug or some
userspace bug is triggered by this. Changing the compiler to clang
then the problem is also gone. Still investigating.

Powered by blists - more mailing lists