The change (removing the function buf_load_throttle_if_needed()) looks OK to me, but I think that we need to test the performance before applying this change.

I would not target 10.3, but rather 10.5 or 10.6. The buffer pool I/O layer works quite differently before 10.5 switched to a single buffer pool (MDEV-15058) and optimized the page cleaner thread (MDEV-23399, MDEV-23855).

Being single threaded in 10.3, 10.4 (before MDEV-26547) there was only page request in transit at a time and saw this as a lower impact. The original user in SO post was using 10.4 (based on other questions about the same time).

Benchmark results. I have tested 3 setups:

1. MariaDB-10.6 @ 6d40274f65b, no buffer pool preloading (A)
2. same commit, preloading 90% of buffer pool (B)
3. PR#2339 on top of that commit, preloading 90% of buffer pool (C)

The buffer pool was 32G (with 16G redo) holding 128M rows in 32 tables, totaling 30GB of raw data. The pool was once created with slow shutdown, hence it was completely merged and purged. The pool was recreated from a tarfile for each run.

I tested 4 different workload scenarios:

1. how it takes to complete the loading of the buffer pool without load
2. how long it takes to mysqldump the OLTP database (to /dev/null)
3. throughput for OLTP read/write with 1 thread over 15 minutes
4. throughput for OLTP read/write with 32 threads over 15 minutes

Numbers:

sysbench OLTP read/write is better viewed as time series plot:

The same data for the datadir on SSD:

time series. For 32 thd only the first 5 min are shown

Verdict: the server behaves very similar with or without PR#2339. OK to go.

Thank you, danblack and axel! In hdd_32_thd.png the right column is for loading the buffer pool with the patched version. Both those graphs and hdd_1_thd.png are only indicating an improvement, never any serious regression. So, removing the throttling seemed to be the right thing to do.