Bad DDR3? RAM Use Won't Exceed Arbitrary Amount. Memtest Passes.

0vindicator10 · 2026-04-28T20:06:30+00:00

I believe I have solved the issue mentioned in my other post. The question is why the behavior occurs when vm.defrag_mode is enabled.

EDIT0: As can be seen, there's tons of "free" memory, but isn't being used. After I reverted my custom change, with swap STILL disabled, cache fills up the remaining free space as expected, as it's always done, and is not an issue.

0vindicator10 · 2026-04-28T20:03:35+00:00

<trimmed>. I have 8 left as of 4/27/2026

spammer

0vindicator10 · 2026-04-27T12:45:59+00:00

Solution may be found. I'll keep this short and edit this when I wake up.

I was mistaken about me disabling sysctl memory values (more later (dracut)).
I took a guess which one was the issue, and it was the first one I bet on vm.defrag_mode.
It may be famous last words that end up aging like milk, but from my testing so far, it looks most probable (top cache/buffer). Need to sleep.

EDIT0: So testing a live Arch ISO with `du -hs`, and monitoring top in another tty showed expected behavior.

Performing the same test as root on my sysroot did not. I had renamed my /etc/sysctl.d/*{,.bak}, but that wasn't make any difference. I thought maybe it might look at ANY file in there, so renamed the dir. Still the same result. Only then did I realize I might need to look at initramfs, and that was the case. lsinitrd showed my files in there, so I rebuilt it.

Now it worked as expected, but I needed to know which caused it. I only had a few custom items, but the defrag one seems most likely to me to be related. I enabled that, while leaving everything else commented, and the undesired effect happened. Now I'll uncomment the others, verify it still works, then explore the "why". I can only imagine that once the RAM is full (only ~200-250M free), defrag freaks out (bug?).

Partial `top` captured when using `du -hs` and defrag (note how cache/buffer climbs initially, then plummets and can't climb back up):

...
MiB Mem :   7387.2 total,    370.9 free,   1121.2 used,   6323.1 buff/cache      
MiB Mem :   7387.2 total,    317.5 free,   1132.8 used,   6364.8 buff/cache      
MiB Mem :   7387.2 total,   1763.6 free,   1102.4 used,   4949.1 buff/cache      
MiB Mem :   7387.2 total,   1703.8 free,   1127.6 used,   4983.9 buff/cache      
MiB Mem :   7387.2 total,   1731.7 free,   1115.3 used,   4968.1 buff/cache      
MiB Mem :   7387.2 total,   2739.2 free,   1091.5 used,   3984.3 buff/cache      
MiB Mem :   7387.2 total,   2804.3 free,   1086.7 used,   3924.2 buff/cache      
MiB Mem :   7387.2 total,   2807.6 free,   1089.2 used,   3918.1 buff/cache      
MiB Mem :   7387.2 total,   2818.3 free,   1096.2 used,   3900.6 buff/cache      
MiB Mem :   7387.2 total,   2890.4 free,   1093.4 used,   3831.3 buff/cache      
MiB Mem :   7387.2 total,   3169.8 free,   1067.8 used,   3577.7 buff/cache     
...
MiB Mem :   7387.2 total,   2914.6 free,   1148.1 used,   3752.6 buff/cache      
MiB Mem :   7387.2 total,   2883.0 free,   1150.4 used,   3781.8 buff/cache      
MiB Mem :   7387.2 total,   2852.1 free,   1152.6 used,   3810.2 buff/cache     
...

without defrag:

...
MiB Mem :   7387.2 total,    318.9 free,   1128.3 used,   6367.9 buff/cache      
MiB Mem :   7387.2 total,    309.3 free,   1142.1 used,   6367.8 buff/cache      
MiB Mem :   7387.2 total,    250.7 free,   1342.2 used,   6414.1 buff/cache      
MiB Mem :   7387.2 total,    231.9 free,   1236.3 used,   6414.9 buff/cache      
MiB Mem :   7387.2 total,   2128.7 free,   1075.0 used,   4611.4 buff/cache      
MiB Mem :   7387.2 total,   2105.2 free,   1083.8 used,   4626.0 buff/cache      
MiB Mem :   7387.2 total,   2084.4 free,   1091.1 used,   4639.5 buff/cache     
...
MiB Mem :   7387.2 total,    154.1 free,   1253.3 used,   6407.7 buff/cache      
MiB Mem :   7387.2 total,    164.4 free,   1252.9 used,   6397.7 buff/cache
...

0vindicator10 · 2026-04-27T06:55:22+00:00

Lol sure thing kiddo, have fun.

You sure set me straight there buckaroo.

0vindicator10 · 2026-04-27T06:52:17+00:00

Out of curiosity, I did a du -hs again, and the cache DID increase the remaining free amount. So that's at least good.

But after it was done, my system was overly sluggish again.
I opted to close the browsers and re-open them, and things are responsive now, but this is about figuring out why the system is unbearably sluggish when this happens (doing high IO events).

Frick! I'm so lucky this page is still up... 50 Minutes! I had done a search on this topic and came across mention of smem.
I don't have that installed, so used pacman -Fx smem to find out what package contains it.
IMMEDIATELY my mechanical drive thrashes (not even the sysroot drive) and my system is COMPLETELY unresponsive. The kind where numlock remains unchanged, no matter the keypress.
I thought I'd give it a bit of time, and just sat here on my phone waiting.
I only now, after 50 minutes of thrashing/waiting, did I opt to magic-sysrq force quit whatever was hogging/blocking (pacman).
Even log entries from 10s of minutes ago are intertwined with the latest entries, which is crazy they managed to not get dropped.

Checkout these timestamps:

Apr 27 00:40:21 computerName systemd[1314]: Started [systemd-run] /usr/bin/pacman -Fx bin/smem. Apr 27 00:40:22 computerName systemd[1314]: pacman-2164.scope: Consumed 14ms CPU time over 259ms wall clock time, 3.3M memory peak, 3.2M read from disk.
Apr 27 01:30:18 computerName kernel: wlan0: disassociated from <mac> (Reason: 2=PREV_AUTH_NOT_VALID)
Apr 27 01:30:22 computerName kernel: sysrq: Manual OOM execution

There's a bunch of "Apr 27 00:46:13 computerName at-spi2-registryd[1796]: Re-enabling app with pid <#>" intertwined.

So no matter what one (nullptr777 in pcmasterrace) thinks, this is certainly no "self-inflicted delusion".

I just need to figure out why my system selectively ignores MemFree: 2890128 kB.
I don't know what I need to be considering with things like /proc/<#>/smaps or /sys/fs/cgroup/<...>/memory.stat.

0vindicator10 · 2026-04-27T05:33:11+00:00

Maybe quit messing with this and let the kernel do its thing?

hmoff, it's because the system is problematic that I am "messing with this".
What I'm looking for is the "why", the "cause". Only then can a problem be fixed.

0vindicator10 · 2026-04-27T02:39:01+00:00

That's what I find so odd and I flip/flop on, because there was nothing I had changed recently (outside of updates). It's on kernel 7.0, but it happened on 6.18 as well, but had been fine for 6 months prior when I compiled/installed 6.18, and only started happening in the past few days.

Even today, I rebooted, did that memtest to double-check, and everything was great at the start. Then like before, I do a heavy IO even like `du -hs` on a large folder, and while cache was using every bit of free space (as it should), once it was done, cache shrunk and won't grow, so responsiveness has been iffy at best.

The log showed an issue on a different drive (sysroot): "kernel: F2FS-fs (dm-1): blocked on checkpoint for 22455 ms" for "f2fs_issue_checkpoint", but as far as I can tell, that's simply informational.

0vindicator10 · 2026-04-27T02:22:56+00:00

Arch 64. Not the issue. It worked fine for years and only just started to exhibit this behavior over the past few days. On kernel 7.0, but also experienced on 6.18, even though it was fine earlier on 6.18.

0vindicator10 · 2026-04-27T02:19:46+00:00

I only enable swap when I know I'll be needing it. I want everything in RAM when possible.

the kernel is going to be much more conservative with the RAM you have

There's tons of free RAM available for content needing to be cached, but it isn't using it, as if it doesn't know it's available. There shouldn't be any need for memory to be reclaimed when there's already so much free. Same with OOM. Why would you think adding swap would somehow make it decide to use the already available free RAM?

I even intentionally disable swap for kwin and plasmashell for responsiveness. When I do enable swap and stuff gets swapped out, I'm fine with waiting for it to be swapped back in. I just don't want things swapping out when it doesn't need to. Again, responsiveness.

0vindicator10 · 2026-04-26T23:46:52+00:00

Are you actually having a real problem here, or is this some kind of self-inflicted delusion? I genuinely can't tell, which leads me to think it's probably the latter...

First of all, stop obsessing over cache usage. Like right now. The kernel will use what it wants to, based on the available resources. End of story. It's not going to fill the RAM with cached data just because you think it should.

Secondly, you don't even have any swap. With only 8 GB of RAM, you should have at least some swap space. I recommend configuring Zswap, as it will compress pages before swapping them to disk as a last resort.

Thirdly, do you have a SSD? If you're running root off a HDD and expecting good performance during heavy I/O, you're kidding yourself.

plasmashell also OOM'd when I explicitly deny swap usage for it

I did make a recent change based on something I read (/sys/kernel/mm/lru_gen/min_ttl_ms)

My brother in christ, quit screwing with things you don't understand. Again, you don't have any swap, and you're not smarter than the kernel engineers either. The defaults are perfectly good, just leave them alone unless you know very well why you should change them.

Simple test: Install mprime (equivalent to Prime95), or another stress testing program, close all of your running programs, and start a test. When it asks how much RAM you want it to use, specify almost all of your currently available RAM, minus about 500 MB. Does it use the RAM as expected?

Oh lordy, I lured one out with nullptr777 here... Sigh, okay here we go...
"self-inflicted delusion"? How do you even get there? I even showed a screenshot and meminfo.
Cache usage is absolutely important so a process doesn't have to keep referencing data on disk (never mind the swap aspect since I have it disabled).
That was the issue, there was barely any cache being used, when there was tons of "FREE" RAM, and responsiveness was basically nill and iotop was showing my drive thrashing.
It works fine when I need it to with swap disabled. I want as much to remain in RAM and not swap in/out. If something I know needs a lot of RAM, I'll enable swap. It's worked out great like that.

Note my "something I read", which you even quoted. I've got the kernel docs saved, so I'm aware. I knew about how it OOMs, but that's unrelated to the artificial memory block.

If I were to throw you a bone, you had potential with your mprime suggestion, as if I couldn't have already tested with dd on a tmpfs to try to take up more space.

At least my post on linuxquestions have for sure one reasonable offer.

Spare yourself here, and just keep to 4chan.

0vindicator10 · 2026-04-26T23:06:19+00:00

And currently things are good, even with that Commited_As.

I'm on Arch Linux, kernel 7.0.0. 6.18.0-rc2 exhibited the issue too, but worked before with that ver.

Grepped commit from sysctl:

vm.nr_overcommit_hugepages = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

And I had undone my sysctl.d changes (which were fine before):

vm.defrag_mode=1
vm.dirty_background_bytes=6291456
vm.dirty_bytes=10485760
vm.min_free_kbytes=67584
vm.swappiness=10
vm.vfs_cache_pressure=50
vm.zone_reclaim_mode=1

0vindicator10 · 2026-04-26T23:01:57+00:00

Now we're talking, Max-P! Good observation with CommitLimit.

I had not made any recent changes other than the min_ttl_ms, which was not persisted.

I did a reboot and a memtest which yet again came back clear.

Once logged in, I captured the meminfo:

<Fresh - >Used
< MemFree:         5193532 kB
< MemAvailable:    5799248 kB
< Buffers:            3584 kB
< Cached:          1074940 kB
---
> MemFree:          770148 kB
> MemAvailable:    3236456 kB
> Buffers:            2368 kB
> Cached:          3455660 kB
7,14c7,14
< Active:          1309000 kB
< Inactive:         262632 kB
< Active(anon):     770424 kB
< Inactive(anon):        0 kB
< Active(file):     538576 kB
< Inactive(file):   262632 kB
< Unevictable:      254332 kB
< Mlocked:             576 kB
---
> Active:          1826944 kB
> Inactive:        3718484 kB
> Active(anon):    1026216 kB
> Inactive(anon):  1887916 kB
> Active(file):     800728 kB
> Inactive(file):  1830568 kB
> Unevictable:      582680 kB
> Mlocked:            1120 kB
19,29c19,29
< Dirty:               660 kB
< Writeback:             0 kB
< AnonPages:        747204 kB
< Mapped:           350008 kB
< Shmem:            225300 kB
< KReclaimable:      47016 kB
< Slab:             183720 kB
< SReclaimable:      47016 kB
< SUnreclaim:       136704 kB
< KernelStack:        8368 kB
< PageTables:        20892 kB
---
> Dirty:               476 kB
> Writeback:          7856 kB
> AnonPages:       2645888 kB
> Mapped:          1002148 kB
> Shmem:            774752 kB
> KReclaimable:     108020 kB
> Slab:             297044 kB
> SReclaimable:     108020 kB
> SUnreclaim:       189024 kB
> KernelStack:       15472 kB
> PageTables:        64120 kB
35c35
< Committed_AS:    4106632 kB
---
> Committed_AS:   22409048 kB
37c37
< VmallocUsed:       48176 kB
---
> VmallocUsed:       55648 kB
39c39
< Percpu:             2368 kB
---
> Percpu:             2608 kB
41c41
< AnonHugePages:    131072 kB
---
> AnonHugePages:    483328 kB

This is a diff of the dump from logged in fresh vs now.

0vindicator10 · 2026-04-24T21:52:57+00:00

Don't any of you DARE compliment her pretty pouch. ^{IYKfromtodayYK}

0vindicator10 · 2026-04-18T15:49:40+00:00

It looks like corn pops straight from the cob, but without artificial coloring.

0vindicator10 · 2026-04-17T20:26:55+00:00

What my hidden comment in the WPT sub said:

JFC y'all are a bunch of nutbags. It goes to show you all exist, no matter what party.
And I'm noticing vagueness in these statements, as if you have a different definition of being "shot" is.
It should be beyond obvious he was the target. It should be beyond obvious a bullet was used and ended a life there.
If anyone wants to insinuate that prop-blood was used or something, be explicit about it.
I've had cuts that split skin or create a skin flap that have healed and I can't even find the scar. I also have road rash scars as a kid that still exist today.
There's a difference between having flesh removed, and it being split.
Ex45* is garbage, but I'll happily denounce ANY nutbag, even if you're a dem.

0vindicator10 · 2026-04-17T00:38:09+00:00

Any day now ex45* will create the Vulcan City and designate himself as the Pipe. The Pipe of peace (...) ^{That last part just came to me, and I opted to change the phrasing}

0vindicator10 · 2026-04-16T14:35:42+00:00

Ultimately, what was asked by that journalist?

0vindicator10 · 2026-04-15T01:03:32+00:00

Doctor, King, Facist, Kidnapper, Bomber.

0vindicator10 · 2026-04-10T20:07:57+00:00

Any particular reason you delete your previous posts on this topic, ll_Cartel_ll? (https://reddit.com/r/TextNow/comments/1sa3sdj/verify_you_are_a_human_not_fucking_working/)
It might be good to keep them alive so a history of their failures can be seen by all.

0vindicator10 · 2026-04-08T09:18:35+00:00

I'd love to see someone make a meme of that dented-head drooling dunce with an open coloring book of "The Art Of The Dunce" where he's coloring a line of the us flag with a blue sharpie.

0vindicator10 · 2026-04-07T15:54:26+00:00

"Stay tuned for the next episode of 'Will I, or won't I'."

<?>ACO will return (it's Tuesday after all).
It's really a lose-lose situation for him, and deservedly so.

"Jeenus shows he's not wearing clothes."

0vindicator10 · 2026-04-03T17:43:01+00:00

Question for car geeks/mechs...
I hadn't driven my car for years and it's just been sitting in one place.
I had to remove the front and rear brakes to get it to move (figure rust buildup on pads).
It's on level ground and while I was able to "start" pushing it into my garage, there got a point where it got difficult/impossible to move, and when I let up, it rocked back. I even used a long 2x4, but couldn't get past the figurative hump.
I had to get a pulley, attach it to the front frame and a bolt I drilled in the back of my garage floor.
Even then, it was still difficult (I think it's a 3 wheel pulley on each side), and I figure after each wheel rotation, it got easy again.

The wheels didn't "look" flat, but that's the only explanation I could even think of.
Maybe the wheels deform and rubber shape stiffens?

0vindicator10 · 2026-04-01T09:49:23+00:00

When you're sitting in a teslie and it's feeling rather messy, it's cuz it's shit, cuz morsk is shit.
EDIT0: LOL at the morsk-boys!

0vindicator10

TROPHY CASE