https://github.com/MariaDB/server/commit/359a6e6405cf720c0e24e579f74f50d3d7d5f5ae is the POC. No measurable gain in the log file on 1 10G pool/1M chunksize.

2021-07-20 17:25:34 0 [Note] InnoDB: Using liburing

2021-07-20 17:25:34 0 [Note] InnoDB: Initializing buffer pool, total size = 10737418240, chunk size = 1048576

2021-07-20 17:25:34 0 [Note] InnoDB: Completed initialization of buffer pool

2021-07-20 17:25:34 0 [Note] InnoDB: Setting O_DIRECT on file ./ibdata1 failed

However I'll test this again on a bigger machine.

It could be that the removal of buf_block_t::mutex in MDEV-15053 (MariaDB Server 10.5) sped up the buffer pool initialization. In 10.6, the MDEV-24142 replacement of buf_block_t::lock with something simpler could have helped as well. I think that we may want to create a special version of buf_block_init() that would debug-assert that all memory is already zero-initialized. That special version would be used when allocating the buffer pool, but not during normal operation, where the block descriptors might contain some garbage that needs to be cleared.

Is this work motivated by or related to PR#1548?

it was mainly a place to attempt a POC of doing something in parallel using omp that wasn't complicated, very little code changes, and would fail impressively if I got it wrong (in CI). The Tencent folks mentioning it made me think of it. There wasn't any real thought as to intermediate changes that improved this already. But yes, doing something lazy like MDEV-25340 might be something better to benchmark for a real change

The buffer pool initialization in MariaDB Server 10.6 is already pretty fast according to tests that I conducted: less than 1 second to start up, bootstrap and shut down a server with innodb_buffer_pool_size=96g.

Would this contribution be made redundant by MDEV-29445 (removing the current-form buf_pool.chunks) and MDEV-25340 (lazy initialization of the buf_pool.free list)?