I just discovered this so throwing this out here quickly before life rushes by and I don’t share.
So far it seems to be fixing my issue but I’ve only been running the fix for a few hours. Also I did reduce some of the stuff I had open.
I’ve got the long dump from Github Copilot stored away in a note and not gonna share that here, but basically AI ran thru a bunch of logs and eventually determined that vm.min_free_kbytes was set too low and I re-adjusted it to 1GB. Now performance seems to be much better.
Ultimately for the fix I created /etc/sysctl.d/99-memory-optimization.conf with this:
# Increase minimum free memory from ~66MB to 1GB
# This ensures the kernel has enough contiguous memory for critical allocations
vm.min_free_kbytes = 1048576
Backstory:
I have a decently-sized large git repo with several submodules which are typically fully initialized.
When I opened it up in VSCode, one of my machines (KFocus Iridium14) - which btw only has 16GB of RAM - was locking up a bit periodically.
It seems that I had a bunch of memory used, and while there was that could be reclaimed when opening this repo, it wasn’t getting reclaimed fast enough.
More details from copilot:
Let me break down the memory from the unreclaimable=yes moment:
active_anon: 5944336 kB = 5.7 GB (Chrome heap/stack, VS Code, etc)
inactive_anon: 2729104 kB = 2.6 GB (Swappable process memory)
active_file: 1677116 kB = 1.6 GB (Hot page cache - files in memory)
inactive_file: 1684912 kB = 1.6 GB (Cold page cache - can be evicted)
shmem: 2384328 kB = 2.3 GB (Shared memory, tmpfs)
unevictable: 681320 kB = 0.7 GB (Locked/pinned memory)
kernel_stack: 39232 kB = 0.04 GB (Kernel memory for threads)
pagetables: 187620 kB = 0.2 GB (Memory for page table structures)
---
TOTAL: ≈ 15.7 GB (of 16GB RAM)
EOF
**All 16GB is accounted for!** Here's what's consuming it:
| Category | Size | What It Is |
|----------|------|-----------|
| **active_anon** | 5.7 GB | Chrome (700MB), VS Code, Firefox, processes actively using RAM |
| **inactive_anon** | 2.6 GB | Process memory that could be swapped but isn't needed right now |
| **shmem** | 2.3 GB | Shared memory, tmpfs files, shared libraries |
| **inactive_file** | 1.6 GB | File cache (readable from disk if needed) |
| **active_file** | 1.6 GB | Hot file cache (files actively accessed) |
| **unevictable** | 0.7 GB | Locked DMA buffers, mlock'd memory |
| **Kernel structures** | 0.2 GB | Page tables, kernel stacks |
**The real problem:**
- **5.7 GB cannot be freed** - it's actively used by running processes
- **2.3 GB shmem is quasi-locked** - shared memory isn't easily reclaimable
- Only **3.2 GB of file cache** is truly reclaimable without killing processes
- When file cache gets evicted, **it takes time** and causes I/O
- **Meanwhile**, WiFi driver needs a 64KB **contiguous block** immediately for DMA
The kernel **cannot** magically create free memory when all 16GB is committed to something. The fragmentation crisis happens because:
1. Kernel needs 64KB contiguous → searches through fragmented free pages
2. File cache eviction starts (slow, disk I/O)
3. While waiting, more allocations pile up
4. System becomes unresponsive
And why memory is unreclaimable:
User: why is the memory not reclaimable?
GitHub Copilot: Looking back at the kernel logs, the "all_unreclaimable? yes" indicates memory that the kernel **cannot** reclaim to satisfy new allocation requests. Here's why:
Ran terminal command: grep -A 20 "all_unreclaimable\?" /tmp/dmesg_sample.txt 2>/dev/null || dmesg | grep "all_unreclaimable" | tail -5
Ran terminal command: sudo dmesg | grep -E "slab_unreclaimable|unevictable|page allocation failure" | tail -20
Perfect! Looking at the memory breakdowns when `all_unreclaimable? yes` occurred:
slab_unreclaimable:126193 (126MB kernel-internal memory)
unevictable:681320kB (681MB locked/pinned memory)
active_anon:5944336kB (5.9GB actively used by processes)
The reason memory becomes **unreclaimable**:
1. **Chrome holding 700MB+** - actively used, won't be paged out
2. **unevictable memory (681MB)** - This is the key issue:
- Memory explicitly locked by processes (via `mlock()`)
- DMA buffers pinned by `iwlwifi` driver
- Once pinned, **cannot be swapped or evicted**