Why would `make world` slow down with dual channel RAM?

Should chip on the RAM tell you more info and then try to search for it ? Have you tried to check with Lenovo community ? They will know - or just quick Help email trough lenovo website ? Does Lenovo website tells you extensive ram info when you put your serial model?
 
Should chip on the RAM tell you more info and then try to search for it ? Have you tried to check with Lenovo community ? They will know - or just quick Help email trough lenovo website ? Does Lenovo website tells you extensive ram info when you put your serial model?

I don't think that would tell me more than reading the SPD would tell me. The SPD contains the latency values that the RAM module will suggest to the BIOS during initial startup. In overclocking boards you can overwrite those values.
 
I don't think it works like that. Do you have a reference for this?
I got curious so started to look for and i have this reddit post and this post and then you cna read actual Lenovo website
EDIT from lenovo website

Does the size of the RAM modules matter for dual-channel memory?​

Yes, the size of the random access memory (RAM) modules does matter for dual-channel memory. To fully leverage the benefits, it's essential to use a matching pair of RAM modules with the same capacity. While it's possible to mix sizes, the system will only utilize the capacity of the smaller module for dual-channel operations. For optimal performance, aim for identical capacities, speeds, and timings when selecting RAM modules for a dual-channel configuration.

Does dual-channel memory require special RAM modules?​

Dual-channel memory doesn't require special random access memory (RAM) modules, but for optimal performance, it's recommended to use a matched pair of memory modules. These modules should have the same capacity, speed, and timings. Using mismatched modules may still work, but the system will operate at the speed of the slower module, potentially negating the benefits of dual-channel configuration.
 
I got curious so started to look for and i have this reddit post and this post and then you cna read actual Lenovo website

Does the size of the RAM modules matter for dual-channel memory?​

Yes, the size of the random access memory (RAM) modules does matter for dual-channel memory. To fully leverage the benefits, it's essential to use a matching pair of RAM modules with the same capacity. While it's possible to mix sizes, the system will only utilize the capacity of the smaller module for dual-channel operations. For optimal performance, aim for identical capacities, speeds, and timings when selecting RAM modules for a dual-channel configuration.

Hm. Interesting.
 
As another interesting observation, the `make world` time goes up significantly when I properly close the laptop case with all screws:
Seems like you need the vaxorcist.

OK, seriously. Timing can be affected by electrostatic levels, so closing the lid may well dampen the signals on the memory bus enough to add an additional waitstate. With the frequencies involved, digital circuits are increasingly black magic.
 
Now that I think about it, maybe the 16 GB DIMM had higher latencies?
Install sysutils/i2c-tools, there's a "decode-dimms" utility that I've used in the past to get timing etc.
I don't remember if I had to do anything else like loading kernel modules etc, but it surely prints the information you need. Once you do, please post it here.

Another note: for the laptop I'm writing this on I also required more memory because it only had 8GB. My choice at the time was to either replace them both (for max memory) or try to find a matching module (for 16Gb). I was - quite easily - able to find and procure the exact same module for 20€ (much less than 2 new larger modules) on Ebay. There's quite a few companies that recycle hardware and will sell the perfect match to the existing memory.

Exact model numbers will also help add more eyes to your problem. Is it this one? I can't find any reference to that 48Gb but the possible CPUs do match in the AMD-version PDF, although the Intel-version PDF does state this. A specific SKU or S/N will probably help make sure everyone is looking at the same specs/guides etc.

Yeah, I think it is time to read the SPD info off that module. I wonder where I put the Winblows install for that laptop...
A Windows2Go USB stick or external harddrive is always useful to have. Rufus can do this (although I haven't had any luck getting it to work :p) and there's another commercial tool with a free version as well (which did work for me).
 
I should start over and do a full set:
  • Start testing with the 16 GB soldered only (single channel 3200 MHz)
  • Test with the same 16 GB Lenovo module I initially did (dual channel 2666 MHz)
  • Test with another 16 GB module (Crucial) that I have floating around, which is 3200 MHz
  • Test with the 32 GB G.Skill module again
  • case open for all tests

Since MSFS2024 doesn't load for anybody right now I even might have time for it. What's up with that, anyway?

But I need infrastructure to get the memory timings from SPD and a better bandwidth benchmark first.
 
Install sysutils/i2c-tools, there's a "decode-dimms" utility that I've used in the past to get timing etc.
I don't remember if I had to do anything else like loading kernel modules etc, but it surely prints the information you need. Once you do, please post it here.

Out of luck I think:
Code:
% sudo decode-dimms 
SMBus device not found

I don't see a kernel module that I could load. Nor do I think one is needed, I did some i2c programming in the past.

I'll fire up memtest86, I seem to remember that it displays the timings.
 
To make that clear: even though the memory speed is faster, the make buildworld is slower?

Maybe you can test one thing, limit the amount of memory using a kernel knob so both settings have the same amount.

Several decades ago the university course about operating systems had a detail about a paging anomaly where some algorithms for page reclaim would produce suboptimal results in very specific scenarios. It might be that your faster memory config hits the bad spot here, and even though the other configuration is slower, the algorithm works better. I'll check if the Hennessy & Patterson has a reference about this.
 
I'll fire up memtest86, I seem to remember that it displays the timings.
yes, it shows various timing informations. Used it a few weeks ago to verify some incompatible memory on an N305 box that randomly crashed during setup...

To make that clear: even though the memory speed is faster, the make buildworld is slower?
It seems I also had that mixed up. If I now understood correctly exactly this is the case - the 16GB has faster benchmark numbers but is slower for buildworld than the 32GB, which gets lower measurements...
So some anomaly with sub-optimal paging in dual-channel mode really might be the case - or because of that weird "some parts are dual-channel, some aren't" thing lenovo is doing here...
 
To make that clear: even though the memory speed is faster, the make buildworld is slower?

Maybe you can test one thing, limit the amount of memory using a kernel knob so both settings have the same amount.

Several decades ago the university course about operating systems had a detail about a paging anomaly where some algorithms for page reclaim would produce suboptimal results in very specific scenarios. It might be that your faster memory config hits the bad spot here, and even though the other configuration is slower, the algorithm works better. I'll check if the Hennessy & Patterson has a reference about this.

Yes, the supposed dual channel solution benchmarks faster (as expected) in Stream. But it is slower in `make world`.

Good idea about the limit, eliminates some OS factors.
 
I don't see a kernel module that I could load. Nor do I think one is needed, I did some i2c programming in the past.
I hadn't checked it yet, but I've compiled it into my custom kernel. There's a module (depending on smbus):
Code:
ll /boot/kernel/jedec_dimm.ko  
-r--r--r--  1 root wheel   28K Nov  2 01:46 /boot/kernel/jedec_dimm.ko
 
I hadn't checked it yet, but I've compiled it into my custom kernel. There's a module (depending on smbus):
Code:
ll /boot/kernel/jedec_dimm.ko 
-r--r--r--  1 root wheel   28K Nov  2 01:46 /boot/kernel/jedec_dimm.ko

I loaded that but it still doesn't find an SMBus device.
 
I loaded that but it still doesn't find an SMBus device.
kldload smbus smb?
What I have in my kernel:
Code:
> kldstat -vv | grep smb | grep -v ich | grep -v acpi
                212 smbus/smb
                211 nexus/smbios
                125 smbus/jedec_dimm
                118 iicsmb/smbus
                117 iicbus/iicsmb
"ichsmb" is intel stuff, not applicable to AMD. "nexus/smbios" no idea either. The others should be there.
There are 2 modules for AMD systems: kldload amdpm amdsmb
Do you have any smb devices showing up? ls /dev/smb*

Things like memory organisation (# of ranks, device width etc) also influence how well they'll operate together, aside from timings.

EDIT: I have edited my message a bit. Be sure to re-read.
 
kldload smbus smb?
What I have in my kernel:
Code:
kldstat -vv | grep smbus
                212 smbus/smb
                125 smbus/jedec_dimm
                118 iicsmb/smbus
                112 ichsmb/smbus4
Things like memory organisation (# of ranks, device width etc) also influence how well they'll operate together, aside from timings.

EDIT: do you have any smb devices showing up? ls /dev/smb*

I only have smbus and jedec_dimm.

Code:
% kldstat -vv | grep smbus
                512 intsmb/smbus
11    2 0xffffffff832af000     2178 smbus.ko (/boot/kernel/smbus.ko)
                534 smbus/jedec_dimm
 
I only have smbus and jedec_dimm.
I have edited my previous message a bit, make sure to re-read. Be sure to load iicsmb as well (bridge between i2c & smb): kldload iicsmb.

I²C & SMB busses aren't generally needed on x86 systems, so nothing is enabled by default (for user access that is).
 
I have edited my previous message a bit, make sure to re-read. Be sure to load iicsmb as well (bridge between i2c & smb): kldload iicsmb.

I²C & SMB busses aren't generally needed on x86 systems, so nothing is enabled by default (for user access that is).

Still no go with decode-dimms.

I did some i2c programming to overclock a 4-processor Opteron875 box. Good times.
 
Back
Top