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

[Thorsten Leemhuis <regressions@leemhuis.info>]

Lo! Top-posting to facilitate processing and CCing the stable list,
maybe someone has heard of a problem.

Thx for the report. The big questions here is: Is that something that is
specific to 6.18.y or does it happen with mainline, too? And does it
still happen with the latest 6.18.y version (there were a few mm fixes)?
Without answers to this question nobody might look into this if we are
unlucky. And a bisection would be ideal, but I understand all that is
not easy if it takes 24h to detect the problem.

Ciao, Thorsten

On 1/29/26 07:10, Robert Dinse 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
> 
> 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 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.
> 
> 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?
> 2. Is there a supported way to disable this feature on x86_64, or could
> it be made user-selectable for debugging/regression purposes?
> 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?
> 
> I’m happy to run test kernels or provide additional inform