pq/libfreemkv
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

iter8: chunk back to 32 MiB on top of Phase-2.5 revert

Browse Source 
iter7's 64 MiB chunks didn't help (23.1 vs iter4's 24.0). Reverting
to 32 MiB so iter8 differs from iter4 by exactly one variable:
Phase 2.5 disabled / direct passthrough mux thread.

Test question: is Phase 2.5 helping at all? If iter8 mean > iter4,
Phase 2.5 has been a net negative on this rig the whole time. If
iter8 mean < iter4, Phase 2.5 is doing what it claimed.
This commit is contained in:
MattJackson
2026-05-17 08:39:27 -07:00
parent 0dc1f12108
commit 8919de5b03
1 changed files with 3 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/io/writeback_file/mod.rs
+3 -9
View File
@@ -73,15 +73,9 @@ use std::path::Path;
use super::writeback::WritebackPipeline; use super::writeback::WritebackPipeline;
/// Granularity at which the Linux writeback pipeline issues /// Granularity at which the Linux writeback pipeline issues
/// `sync_file_range` / `posix_fadvise(DONTNEED)` pairs. /// `sync_file_range` / `posix_fadvise(DONTNEED)` pairs. 32 MiB
/// /// remains the best-tested value.
/// iter7 (2026-05-17): 32 → 64 MiB. iter6 (8 MiB) regressed -8.2 MB/s const WRITEBACK_CHUNK_BYTES: u64 = 32 * 1024 * 1024;
/// vs iter4 (32 MiB), confirming smaller=slower for this workload.
/// Trying bigger to see if fewer-but-larger syncs reduces overhead
/// further. 0.21.14 tried 128 MiB and was reverted — we don't know
/// whether that was measurement noise or a real TCP-buffer / NFS
/// commit issue. 64 MiB is the middle test point.
const WRITEBACK_CHUNK_BYTES: u64 = 64 * 1024 * 1024;
pub(crate) struct WritebackFile { pub(crate) struct WritebackFile {
file: File, file: File,