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

[Robert Dinse <nanook@eskimo.com>]

[-- Attachment #1: Type: text/plain, Size: 4818 bytes --]


      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 <akpm@linux-foundation.org>
> To: Robert Dinse <nanook@eskimo.com>
> Cc: linux-mm@kvack.org, Dave Hansen <dave.hansen@linux.intel.com>
> 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 <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.
>