[Libguestfs] [PATCH nbdkit v2 4/4] cache: Implement cache-max-size and method of reclaiming space from the cache.

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190102/fc93afe0/attachment.sig>