Re: Subject: Regression: CONFIG_ASYNC_KERNEL_PGTABLE_FREE causes memory exhaustion and stalls on busy Cascade Lake server (6.18.7 only)

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 28 Jan 2026 22:10:11 -0800 Robert Dinse <nanook@eskimo.com> wrote:

> 
> Hardware / setup
> ----------------
> - CPU: Intel i9-10980XE (Cascade Lake), all cores overclocked to 4.5 GHz
> - Motherboard: Gigabyte Aorus Master X299
> - PSU: 1200W Seasonic
> - RAM: 256 GB
> - Storage:
>    - MariaDB: RAID1 of two 1 TB NVMe drives
>    - Other storage: RAID1 arrays of spinning disks
> 
> Software
> --------
> - OS: Ubuntu 24.04, with most userland and kernel replaced by 
> self-compiled upstream
> - Kernel:
>    - 6.18.6: stable, previously in production
>    - 6.18.7: regression
> - Toolchain: gcc 15.2
> - Services:
>    - Apache 2.4.65 (self-compiled), with modified exec-php to allow 
> per-user PHP versions via handlers
>    - MariaDB with ~60 GB of tables
>    - InnoDB buffer pool: ~70 GB
>    - Several social media sites and other complex web hosting workloads
> 
> Baseline behavior (6.18.6)
> --------------------------
> Under 6.18.6, the machine behaves as expected:
> - Roughly half of the 256 GB RAM in use, half available
> - Memory usage stable over time
> - Swap usage negligible
> - Web server and database remain responsive under normal production load

Thanks.

> Regression behavior (6.18.7)
> ----------------------------
> After upgrading from 6.18.6 to 6.18.7, the system initially runs 
> normally, but after
> approximately 24 hours of production load:
> - Total memory usage climbs until RAM is fully consumed
> - System goes ~10 GB into swap
> - Web server and database stall intermittently
> - Overall system responsiveness degrades severely
> 
> Reverting to 6.18.6 immediately restores the previous stable behavior.
> 
> Attempt to disable CONFIG_ASYNC_KERNEL_PGTABLE_FREE

I don't understand why you believe this issue was caused by the
CONFIG_ASYNC_KERNEL_PGTABLE_FREE code?

> ---------------------------------------------------
> I attempted to disable the new async kernel page table freeing feature:
> 
> - The symbol `CONFIG_ASYNC_KERNEL_PGTABLE_FREE` appears in `.config`
> - However, it does not appear in xconfig or other configuration frontends
> - Manually editing `.config` to disable it works only until the next `make`:
>    - As soon as I re-run the build, the option is silently re-enabled
> - I tried to chase the Kconfig dependencies, but the chain was too 
> convoluted; it appears to be effectively non-user-selectable and forced 
> on by default for my architecture.

Yes, CONFIG_ASYNC_KERNEL_PGTABLE_FREE is always-on for x86. 
arch/x86/Kconfig has

	select ASYNC_KERNEL_PGTABLE_FREE	if IOMMU_SVA

so removing that line will permit you to disable
ASYNC_KERNEL_PGTABLE_FREE.

I don't know why this is conditioned on IOMMU_SVA=y - that was an
unchangelogged alteration.

Please do persist with the CONFIG_ASYNC_KERNEL_PGTABLE_FREE=n testing.

>  From an operator perspective, this feature as currently implemented is 
> not workable on a busy machine like this, and the inability to disable 
> it makes it difficult to bisect or run with a known-good configuration.
> 
> Current status
> --------------
> - I have reverted to 6.18.6, which remains functional and stable under 
> the same workload.
> - I have attached the '.config' for the affected 6.18.7 kernel.
> - I can also collect additional data (vmstat, /proc/meminfo, slabinfo, 
> etc.) if you tell me what would be most useful.
> 
> Request
> -------
> 1. Is this a known issue with CONFIG_ASYNC_KERNEL_PGTABLE_FREE on 
> large-memory, high-load systems?

Not as far as I know.

> 2. Is there a supported way to disable this feature on x86_64, or could 
> it be made user-selectable for debugging/regression purposes?

That would be good.

> 3. Are there specific traces or statistics you would like me to gather 
> when the system is in the "memory maxed + swap in use + stalls" state?

A starting point would be /proc/*info - try to spot something which
increased a lot.