Unstable File's AsyncManagedReadAt performance when changing global allocator or file flags

[inklesspen1rus]

Issue

I found performance degradation when I change global allocator or open files with O_DIRECT.
Here's benchmarks: https://github.com/inklesspen1rus/compio-mimalloc-issue

• usual_read - Open file with default flags and read with BufferPool with default global allocator
• read_direct - Open file with O_DIRECT and read with BufferPool with default global allocator
• mimalloc_direct - Open file with O_DIRECT and read with BufferPool with MiMalloc global allocator
• mimalloc - Open file with default flags and read with BufferPool with MiMalloc global allocator

By some magically way changing default global allocator to MiMalloc improves performance when reading by 128KiB blocks.
Also, when I combine MiMalloc and O_DIRECT I get huge performance regression.

I guess there is something with buffers' alignment in BufferPool (due to usual Vec there). Probably they do not fit to memory pages.

Benchmark Results

Benchmark	Global Allocator	File flags	Block size	Throughput
usual_read	default	default	4096	1.468 GB/s
			65536	9.681 GB/s
			131072	1.747 GB/s
read_direct	default	O_DIRECT	4096	1.4 GB/s
			65536	9.42 GB/s
			131072	1.727 GB/s
mimalloc_direct	MiMalloc	O_DIRECT	4096	61.56 MB/s
			65536	255.8 MB/s
			131072	321.1 MB/s
mimalloc	MiMalloc	default	4096	1.413 GB/s
			65536	9.806 GB/s
			131072	10.72 GB/s

Environment

rustc 1.91.0-nightly (6c699a372 2025-09-05)
rustc 1.91.0-nightly (6c699a372 2025-09-05)
nightly-x86_64-unknown-linux-gnu

OS: Manjaro Linux x86_64 
Host: Modern 14 C5M REV:1.0 
Kernel: 6.15.9-2-MANJARO 
Uptime: 8 days, 4 hours 
Packages: 1993 (pacman), 29 (flatpak) 
Shell: bash 5.3.3 
Resolution: 1920x1080 
DE: Plasma 6.3.6 
WM: kwin 
Theme: Breeze-Dark [GTK2], Breeze [GTK3] 
Icons: breeze [GTK2/3] 
Terminal: vscode 
CPU: AMD Ryzen 5 5625U with Radeon Graphics (12) @ 2.301GHz 
GPU: AMD ATI 03:00.0 Barcelo 
Memory: 8992MiB / 15360MiB

[Berrysoft]

Well, that's wierd. If you're using io-uring, the buffer pool is allocated by mmap and should not be affected by the global allocator.

[Berrysoft]

I have tried your bench repo, and found that read_direct also got performance regression. Therefore it should be the problem of O_DIRECT.

     Running benches/mimalloc.rs (target/release/deps/mimalloc-546c69d72b263c72)
Timer precision: 100 ns
mimalloc                         fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       752.5 ns      │ 974.1 ns      │ 837.6 ns      │ 839.3 ns      │ 100     │ 50000
   │                             5.442 GB/s    │ 4.204 GB/s    │ 4.889 GB/s    │ 4.879 GB/s    │         │
   ├─ 65536                      2.538 µs      │ 3.382 µs      │ 2.935 µs      │ 2.887 µs      │ 100     │ 50000
   │                             25.81 GB/s    │ 19.37 GB/s    │ 22.32 GB/s    │ 22.69 GB/s    │         │
   ╰─ 131072                     5.285 µs      │ 11.21 µs      │ 6.071 µs      │ 6.327 µs      │ 100     │ 50000
                                 24.79 GB/s    │ 11.68 GB/s    │ 21.58 GB/s    │ 20.71 GB/s    │         │

     Running benches/mimalloc_direct.rs (target/release/deps/mimalloc_direct-d44e7d260990256a)
Timer precision: 100 ns
mimalloc_direct                  fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       138.8 µs      │ 223.2 µs      │ 169.3 µs      │ 171.9 µs      │ 100     │ 50000
   │                             29.5 MB/s     │ 18.34 MB/s    │ 24.19 MB/s    │ 23.82 MB/s    │         │
   ├─ 65536                      247.6 µs      │ 318.4 µs      │ 270.8 µs      │ 272.8 µs      │ 100     │ 50000
   │                             264.6 MB/s    │ 205.8 MB/s    │ 241.9 MB/s    │ 240.2 MB/s    │         │
   ╰─ 131072                     325.5 µs      │ 386.1 µs      │ 344.9 µs      │ 345.1 µs      │ 100     │ 50000
                                 402.6 MB/s    │ 339.4 MB/s    │ 380 MB/s      │ 379.7 MB/s    │         │

     Running benches/read_direct.rs (target/release/deps/read_direct-dadf51508eb7335e)
Timer precision: 100 ns
read_direct                      fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       156 µs        │ 222.9 µs      │ 167.1 µs      │ 169.9 µs      │ 100     │ 50000
   │                             26.24 MB/s    │ 18.37 MB/s    │ 24.49 MB/s    │ 24.09 MB/s    │         │
   ├─ 65536                      249.4 µs      │ 290.3 µs      │ 261.3 µs      │ 262.4 µs      │ 100     │ 50000
   │                             262.7 MB/s    │ 225.7 MB/s    │ 250.7 MB/s    │ 249.6 MB/s    │         │
   ╰─ 131072                     333.5 µs      │ 378 µs        │ 347.4 µs      │ 348.4 µs      │ 100     │ 50000
                                 392.9 MB/s    │ 346.6 MB/s    │ 377.2 MB/s    │ 376.1 MB/s    │         │

     Running benches/usual_read.rs (target/release/deps/usual_read-4c51375b25ceaa17)
Timer precision: 99 ns
usual_read                       fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       610.5 ns      │ 1.207 µs      │ 724.6 ns      │ 730.8 ns      │ 100     │ 50000
   │                             6.708 GB/s    │ 3.393 GB/s    │ 5.652 GB/s    │ 5.604 GB/s    │         │
   ├─ 65536                      2.42 µs       │ 3.747 µs      │ 2.655 µs      │ 2.705 µs      │ 100     │ 50000
   │                             27.07 GB/s    │ 17.48 GB/s    │ 24.67 GB/s    │ 24.22 GB/s    │         │
   ╰─ 131072                     5.441 µs      │ 8.263 µs      │ 6.402 µs      │ 6.446 µs      │ 100     │ 50000
                                 24.08 GB/s    │ 15.86 GB/s    │ 20.47 GB/s    │ 20.33 GB/s    │         │

[inklesspen1rus]

Well, that's wierd. If you're using io-uring, the buffer pool is allocated by mmap and should not be affected by the global allocator.

compio/compio-driver/src/buffer_pool/iour.rs

Line 20 in 4223551

buf_ring: IoUringBufRing<Vec<u8>>,

Seems like there's just Vec, not mmap

Creates with Vec::with_capacity:

compio/compio-driver/src/iour/mod.rs

Line 340 in 4223551

let buf_ring = io_uring_buf_ring::IoUringBufRing::new(

https://github.com/Sherlock-Holo/io_uring_buf_ring/blob/7ff3fe55ff19012c2d122697cb0ba90bf3f3013c/src/lib.rs#L220

I have tried your bench repo, and found that read_direct also got performance regression. Therefore it should be the problem of O_DIRECT.

Regression with O_DIRECT is expected due to its nature.
Unexpected the difference between O_DIRECT and O_DIRECT+MiMalloc and between No-O_DIRECT and No-O_DIRECT+MiMalloc

I test on NVMe drive probably that's gives some effect on O_DIRECT.
Probably there are difference between hardware and there will be difference on higher block sizes, I'll check bench on another machine on next week.

[inklesspen1rus]

Tried to change buffers like this:
mempages.patch

Now there are no difference between mimalloc and global allocator. Also, O_DIRECT benches performs identical w/o local regression:

Timer precision: 907 ns
mimalloc                         fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       2.765 µs      │ 3.478 µs      │ 2.852 µs      │ 2.877 µs      │ 100     │ 50000
   │                             1.481 GB/s    │ 1.177 GB/s    │ 1.435 GB/s    │ 1.423 GB/s    │         │
   ├─ 65536                      6.528 µs      │ 9.067 µs      │ 6.683 µs      │ 6.788 µs      │ 100     │ 50000
   │                             10.03 GB/s    │ 7.227 GB/s    │ 9.805 GB/s    │ 9.654 GB/s    │         │
   ╰─ 131072                     11.08 µs      │ 16.94 µs      │ 13.32 µs      │ 13.16 µs      │ 100     │ 50000
                                 11.81 GB/s    │ 7.734 GB/s    │ 9.839 GB/s    │ 9.952 GB/s    │         │

     Running benches/mimalloc_direct.rs (target/release/deps/mimalloc_direct-34caaf400f222d23)
Timer precision: 489 ns
mimalloc_direct                  fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       29.44 µs      │ 42.69 µs      │ 34.72 µs      │ 34.24 µs      │ 100     │ 50000
   │                             139.1 MB/s    │ 95.92 MB/s    │ 117.9 MB/s    │ 119.6 MB/s    │         │
   ├─ 65536                      33.5 µs       │ 43.44 µs      │ 38 µs         │ 37.84 µs      │ 100     │ 50000
   │                             1.956 GB/s    │ 1.508 GB/s    │ 1.724 GB/s    │ 1.731 GB/s    │         │
   ╰─ 131072                     39.26 µs      │ 48.22 µs      │ 41.84 µs      │ 42.48 µs      │ 100     │ 50000
                                 3.338 GB/s    │ 2.717 GB/s    │ 3.132 GB/s    │ 3.085 GB/s    │         │

     Running benches/read_direct.rs (target/release/deps/read_direct-77084b836e635c7e)
Timer precision: 907 ns
read_direct                      fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       29.4 µs       │ 38.4 µs       │ 34.4 µs       │ 33.44 µs      │ 100     │ 50000
   │                             139.2 MB/s    │ 106.6 MB/s    │ 119 MB/s      │ 122.4 MB/s    │         │
   ├─ 65536                      33.17 µs      │ 65.36 µs      │ 37.63 µs      │ 37.68 µs      │ 100     │ 50000
   │                             1.975 GB/s    │ 1.002 GB/s    │ 1.741 GB/s    │ 1.739 GB/s    │         │
   ╰─ 131072                     38.75 µs      │ 50.23 µs      │ 43.49 µs      │ 43.45 µs      │ 100     │ 50000
                                 3.382 GB/s    │ 2.609 GB/s    │ 3.013 GB/s    │ 3.016 GB/s    │         │

     Running benches/usual_read.rs (target/release/deps/usual_read-46def24211cd4ec1)
Timer precision: 838 ns
usual_read                       fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ compio_read_exact_managed_at                │               │               │               │         │
   ├─ 4096                       2.722 µs      │ 3.73 µs       │ 2.818 µs      │ 2.847 µs      │ 100     │ 50000
   │                             1.504 GB/s    │ 1.097 GB/s    │ 1.453 GB/s    │ 1.438 GB/s    │         │
   ├─ 65536                      6.452 µs      │ 7.412 µs      │ 6.62 µs       │ 6.654 µs      │ 100     │ 50000
   │                             10.15 GB/s    │ 8.841 GB/s    │ 9.899 GB/s    │ 9.848 GB/s    │         │
   ╰─ 131072                     12.96 µs      │ 19.57 µs      │ 13.27 µs      │ 13.6 µs       │ 100     │ 50000
                                 10.1 GB/s     │ 6.697 GB/s    │ 9.876 GB/s    │ 9.636 GB/s    │         │

Seems like manual mmap solves the issue

[Berrysoft]

Well, I haven't reproduced your issue successfully...

[inklesspen1rus]

Well, I haven't reproduced your issue successfully...

I'll try modify benches on next week. Probably MiMalloc depends on L3 cache or something else.

[inklesspen1rus]

Tried to modify & reproduce on VPS but unsuccessfully... Seems like machine-/platform-dependent issue

the buffer pool is allocated by mmap

At least, I can say surely the buffer pool is not allocated by mmap, there is just Vec::with_capacity
So I suggest to use mmap explicitly instead of Vec to be sure performance is not affected by buffers' alignment (and global allocator), what you think about that?

[Berrysoft]

Yes, you're right. The buffers are not allocated by mmap. However, what I could not reproduce is that, the performance is high enough when O_DIRECT enabled and std allocator is used. Therefore I don't think the performance regression is caused by simply changing an allocator.

[Berrysoft]

Well, actually I cannot find the real problem up to now. You have said that,

Regression with O_DIRECT is expected due to its nature.

Yes, so there's performance regression but it is expected. Furthermore, my benchmark shows that mimalloc behaves nearly the same as std allocator. I don't see a reason to change Vec<u8> to mmap.