Whatever WAS the issue was resolved in 6.18.8 so I withdraw this bug report as it is no longer applicable. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874. On Mon, 9 Feb 2026, Andrew Morton wrote: > Date: Mon, 9 Feb 2026 18:20:49 -0800 > From: Andrew Morton > To: Robert Dinse > Cc: linux-mm@kvack.org, Dave Hansen > Subject: Re: Subject: Regression: CONFIG_ASYNC_KERNEL_PGTABLE_FREE causes > memory exhaustion and stalls on busy Cascade Lake server (6.18.7 only) > > On Wed, 28 Jan 2026 22:10:11 -0800 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 > > 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. >