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:
matthew
2026-05-17 09:49:03 -07:00
parent 4d44856270
commit 42ed23380b
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,