Mo RAM, Mo Problems (2025) (opens in new tab)

Around the turn of the millennium I had a Sony Vaio 505TX, which had the same chipset. My machine was running Linux, and I maxed it out to 128MB RAM.

There was a kernel patch for this chipset back then, which treated all memory above the lower 64MB as a RAM disk, which could then be used as swap space.

This prioritized the faster portion of RAM while still having very fast swapping.

More RAM running slower is still true today. With AM5 you probably cannot enable EXPO with four ram slots filled vs two. The gap is not that extreme though.

https://www.corsair.com/us/en/explorer/diy-builder/memory/2-...

It is funny to see how these older machines perform at their higher end limits. I'm guessing the idea on this was that if you needed that much RAM, the sacrifice of L2 cache was a worth while trade off.

It was only a few weeks ago that I found out the original BeBOX computers would switch off L2 cache when running in dual CPU mode. It was just a limitation of the memory controller. Again, the thinking of, if you need the extra compute over memory bus it would be a worth while trade off.

This reminds me that on an Amiga 600 or 1200, if you add more than 4 (IIRC?) megabytes of RAM through usual means, the PCMCIA slot becomes unusable due to addressing conflicts.

There are workarounds, of course. For instance, the A1208 expansion has a jumper that limits added memory from 8MB to 4MB explicitly so that PCMCIA can be used.

how funny is this, we used to spend weeks fitting assets into 4MB, and now we spend weeks trying to figure out why a 'Hello World' microservice is OOM-ing in a container with 2GB.

We traded the 'Mo RAM' for 'Mo Layers,' and in the process, we lost the ability to reason about what the hardware is actually doing. Sanglard’s breakdowns are always a sobering cold shower for those of us pampered by modern GC and JITs

Also, internal CPU caches grow over time - in 286 and before, just was not any cache; in 386 first included page cache for mmu - stores tables with mostly used pages; in next generations sometimes advertised grow of page cache.

So yes, even when your cpu could address similar size of ram, possible it don't have enough page cache for your application.

Google says sdram in 1997 was 7 to 10 dollars per megabyte. So 384 would be 3840 not 40,000 am I missing something here?

This would have also still been true even roughly a decade later, during which time the industry was going through a transition from 32-bit computing to 64-bit, and large amounts of RAM read from BIOS in pre-UEFI systems were slower to boot the more memory you had!

Imagine young would-become engineers at the time finding that adding that second stick to their laptop did in fact, not make their systems magically faster.

It sounds like a problem related to memory interleaving. He doesn't say whether the memory modules are identical, my bet is that they differ. Could also be a poor performing motherboard.

Reminds me a bit about installing one of my 128MB 72 pin SIMM modules in a 486, it has the same caching issues. Most board will not accept them anyway (I have both FP and Edo ones) but if you put a lower capacity one in the first slot they will happily boot and accept the full ram amount if all lanes are occupied (which is not a given on all 486 motherboards). Also remember to enable quick ram check or you will be getting more coffee.

Does the language in this not make sense to anyone? Is it trying to say the the L2 cache provided by the chipset is not able to access memory past a specific address?

Many modern apps seem to cache based on total ram installed, and don’t seem to scale well to larger than normal systems. Chrome, I’m looking at you.

My 1997 mainboard had extensible tag-ram, if I remember correctly. Perhaps this is the issue?

Rip Rudy.