RP2040 SPI RAM performance is very poor for most workloads
There are several reasons for this:

- [ ] The page cache is 1-way and keeps no statistics. We could keep statistics about what pages get swapped in/out the most and use n-way caching that could make use of this.
- [ ] The page cache size and mapping could be chosen in a much smarter way. Need to think about how region flushes etc. interacts with this.
- [ ] We could transmit cached pages to RAM in the background using DMA. **NOTE:** It seems like the CSn behavior is pretty crappy with SPI and I haven't managed to get it to behave properly. Moving to QSPI PIO would allow solving this issue at the same time if we're careful to design it to be DMA-friendly.
- [ ] We use SPI, not QSPI. This would require PIO, need to investigate available resources for this.
- [ ] It is not entirely certain why but page rx doesn't work beyond 25MHz even though we use the supposedly 125MHz compatible command. Using a PCB might make this more bearable.
- [ ] The page size is 1KiB. This reduces the amount of hard faults we encounter but it also means we transfer much more data than good caching would need. However reducing the transfer size causes issues (probably on page tx, as page rx seems fine). It's possible that raising CE soon enough would prevent this from happening. As it is not currently tied to SPI, it is possible that it is just raised too late.