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

iter13 base: lock chunk back to 32 MiB after iter12 revert

Browse Source 
iter12 revert restored chunk to 128 (iter11 value) by way of the
revert chain. Setting it back explicitly to 32 for iter13. We're
back to iter8 baseline config (no Phase 2.5, 32 MiB chunks,
DONTNEED, no app-level FileSectorSource buffer, channel depth 32).

iter13 is instrumentation: strace the mux thread during a known-dip
to see where time is actually going.
This commit is contained in:
MattJackson
2026-05-17 09:49:03 -07:00
parent 3394a5b3fe
commit 9d6974df3e
1 changed files with 4 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/io/writeback_file/mod.rs
+4 -7
View File
@@ -73,13 +73,10 @@ 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` pairs. /// `sync_file_range` pairs. 32 MiB is the empirically best value:
/// /// iter8 = 28.7, iter9 (64 MiB) = 27.5, iter11 (128 MiB) = 16.6,
/// iter11 (2026-05-17): 32 → 128 MiB. 0.21.14 tried this under Phase /// iter6 (8 MiB) = 15.8. Locked.
/// 2.5 and reverted; with Phase 2.5 disabled (iter8 baseline) the const WRITEBACK_CHUNK_BYTES: u64 = 32 * 1024 * 1024;
/// tradeoff is different. iter8 (32 MiB) = 28.7, iter9 (64 MiB) = 27.5.
/// Trying 128 to see if the iter9 dip was noise or a real trend.
const WRITEBACK_CHUNK_BYTES: u64 = 128 * 1024 * 1024;
pub(crate) struct WritebackFile { pub(crate) struct WritebackFile {
file: File, file: File,