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