bmap: Tweaked bmapcache algo to piggyback on mdir commits

There's really no reason to immediately commit the bmap to disk, at
least no until the first mdir commit, when we need to at least discard
the previous bmap state.

We already do all the gstate handling in lfs3_mdir_commit anyways, and
piggybacking on mdir commit lets us get rid of the annoying extra mdir
param in lfs3_alloc_ckpoint.

This does mean a slightly higher risk of needing to re-rebuild the bmap
after a powerloss, but in theory only if the user does something weird
like writing to a file and never calling sync. Most on-disk operations
terminate in an mdir commit as that's how any state change becomes
atomically visibile in littlefs.

Saves a nice bit of stack:

                code          stack          ctx
  before:      36920           2368          684
  after:       36920 (+0.0%)   2368 (+0.0%)  684 (+0.0%)

                code          stack          ctx
  bmap before: 38552           2472          812
  bmap after:  38464 (-0.2%)   2400 (-2.9%)  812 (+0.0%)
This commit is contained in:
Christopher Haster
2025-07-29 00:42:40 -05:00
parent 316ca1cc05
commit 726cccfe76
7 changed files with 141 additions and 152 deletions
+3 -3
View File
@@ -61,7 +61,7 @@ code = '''
lfs3.lookahead.off = 0;
lfs3.lookahead.known = lfs3_min(8*CFG->lookahead_size,
CFG->block_count-2);
lfs3_alloc_ckpoint(&lfs3, NULL);
lfs3_alloc_ckpoint(&lfs3);
// create a btree
lfs3_btree_t btree;
@@ -2016,7 +2016,7 @@ code = '''
lfs3.lookahead.off = 0;
lfs3.lookahead.known = lfs3_min(8*CFG->lookahead_size,
CFG->block_count-2);
lfs3_alloc_ckpoint(&lfs3, NULL);
lfs3_alloc_ckpoint(&lfs3);
// create a btree
lfs3_btree_t btree;
@@ -3973,7 +3973,7 @@ code = '''
lfs3.lookahead.off = 0;
lfs3.lookahead.known = lfs3_min(8*CFG->lookahead_size,
CFG->block_count-2);
lfs3_alloc_ckpoint(&lfs3, NULL);
lfs3_alloc_ckpoint(&lfs3);
// create a btree
lfs3_btree_t btree;