On 1/2/19 9:39 PM, Eric Blake wrote:
+static void +reclaim_any (void) +{ + /* Find the next block in the cache. */ + reclaim_blk = bitmap_next (&bm, reclaim_blk+1); + if (reclaim_blk == -1) /* wrap around */ + reclaim_blk = bitmap_next (&bm, 0); + + reclaim_block ();
Even when reclaiming any, should we try to prioritize blocks that are found in the LRU cache's bm[1] but not bm[0], as we do have at least that bit of knowledge about LRU patterns? Otherwise, this can end up claiming the most recently used block, if that happens to be the next block in our cycling through the entire cache. Or is that too much layering violation, where it would unnecessarily tie this code to the current lru implementation?
+} + +static void +reclaim_block (void) +{ + if (reclaim_blk == -1) { + nbdkit_debug ("cache: run out of blocks to reclaim!"); + return; + } + + nbdkit_debug ("cache: reclaiming block %" PRIu64, reclaim_blk);
Where does this prioritize clean blocks over dirty blocks? Or is the .pod change inaccurate given later changes to implementation?
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org