NUMA Testing

Locked

Print view

143 posts

dom: Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator; Posts: 8472; Joined: Wed Aug 17, 2011 7:41 pm

There has been a fair amount of work going on over the last year to improve sdram related performance on Pi4 and Pi5.
A lot of the testing and results discovered are described in this epic thread.

There were observations that 8GB Pi's were (for specific tests) slower than 4GB.
This is largely due to self refresh of sdram costing some of your theoretical bandwidth, and the standard (jedec) timings require more time to spent in refresh for larger sdram sizes.

During investigating this, I did discover that we can do a better. The sdram refresh interval is currently using the default data sheet settings.
You can actually monitor the temperature of the sdram and it reports if refresh at half or quarter the rate can be done.
That allows the overhead due to refresh to be reduced by a half or a quarter which does improve benchmark results.

We got in contact with Micron, and there is was good news. They have said they actually test their 8GB sdram with the 4GB refresh rate timing (rather than the slower jedec timings), and so it was be safe to run the 8GB parts with 4GB timing.

I've also been iterating over dozens of sdram and arm (largely cache and prefetch) related settings.
Typically each night capturing benchmark scores with tweaked settings and any positive results get added to the list of further testing.
If results are positive across a range of tests (e.g. geekbench, jetstream, linux kernel compile, memcpy/memset) we push it out (typically bootloader or firmware).
There have been a number of small boosts over the last year. Typically 1% here and there, but they add up.

There is one other significant issue. When multiple arm cores (and hardware blocks, like display, camera, pcie etc) access sdram, they compete.
From here:

This means that if a page in a particular bank is already open, you cannot open another page within the same bank without first closing the currently open page. Once a page is open, it can be accessed multiple times without the need to reopen it for subsequent operations.

In the worst case, two sdram clients accessing different pages of the same bank, may cause repeated closing and opening of the pages, harming the usable bandwidth you can achieve.
Which pages belong to a bank depends on the physical address lines of the buffers used. We have found that it is pretty common for buffers to be allocated in pathologically bad ways.

NUMA allows us to have more control over this. We can split our sdram, into, say, 8 NUMA regions, and configure the kernel to interleave the allocations between the regions.
In addition the sdram controller allows the address bits used for segmenting the banks to be reconfigured (which we've exposed through eeprom config SDRAM_BANKLOW).

Doing this can result in significant performance boosts of sdram bandwidth constrained (typically multi-core) tasks.

[edit: apt now contain numa supporting bootloader/firmware/kernel, so rpi-update is not required]

TLDR: If you want to test the latest experimental improvements, then run:

Code: Select all

sudo apt update && sudo apt full-upgrade

then edit your bootloader config:

Code: Select all

sudo rpi-eeprom-config -e

adding this line for pi5:

Code: Select all

SDRAM_BANKLOW=1

or this line for pi4:

Code: Select all

SDRAM_BANKLOW=3

and reboot. You should find "/proc/cmdline" contains the line "numa=fake=<n>".

Your Pi may be faster. Run some tests and report any improvements, or if you see any regressions.

dom: Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator; Posts: 8472; Joined: Wed Aug 17, 2011 7:41 pm