Write operation and eviction counters in WriteCountStat

[droideck]

The stats API changes 017a3bd IIUC removed the ability to track several cache metrics that were previously available:

1. Write operation counts (includes + modifies) - (or is it read_ops in WriteCountStat?)
2. Eviction counts (from frequent and recent sets)

While ARCacheWriteStat has the notification methods:

fn include(&mut self, _k: &K)
fn modify(&mut self, _k: &K) 
fn evict_from_frequent(&mut self, _k: &K)
fn evict_from_recent(&mut self, _k: &K)

I wasn't able to understand how to get the metrics from *CountStat structs.

Should it be added as WriteCountStat counters for these operations?

pub struct WriteCountStat {
    pub includes: u64,
    pub modifies: u64, 
    pub freq_evicts: u64,
    pub recent_evicts: u64,
  ....
}

Or am I missing an existing way to access these metrics with the new API? If not, would adding these counters be acceptable?

[Firstyear]

You may want the stats methods here https://docs.rs/concread/latest/concread/arcache/struct.ARCache.html

You'll want to set https://docs.rs/concread/latest/concread/arcache/struct.ARCacheBuilder.html#method.set_reader_quiesce to false, and then you call try_quiesce_stats() manually after each read operation is completed. That should give you the info you need :)

[Firstyear]

Note https://docs.rs/concread/latest/concread/arcache/stats/struct.WriteCountStat.html which impls the counters you want.

[droideck]

You'll want to set https://docs.rs/concread/latest/concread/arcache/struct.ARCacheBuilder.html#method.set_reader_quiesce to false, and then you call try_quiesce_stats() manually after each read operation is completed. That should give you the info you need :)

Oh, nice! I'll check it out... Thanks!

Note https://docs.rs/concread/latest/concread/arcache/stats/struct.WriteCountStat.html which impls the counters you want.

I am not sure, though, that I see the above mentioned stats there. Current stats:

#[derive(Debug, Default)]
pub struct WriteCountStat {
    pub read_ops: u64,
    pub read_hits: u64,
    pub p_weight: u64,
    pub shared_max: u64,
    pub freq: u64,
    pub recent: u64,
    pub all_seen_keys: u64,
}

So, IIUC, it should also probably have:

    pub includes: u64,
    pub modifies: u64,
    pub freq_evicts: u64,
    pub recent_evicts: u64,

And then in impl<K> ARCacheWriteStat<K> for WriteCountStat {, we can add (or something like that)

    fn include(&mut self, _k: &K) {
        self.includes += 1;
    }

    fn modify(&mut self, _k: &K) {
        self.modifies += 1;
    }

    fn evict_from_frequent(&mut self, _k: &K) {
        self.freq_evicts += 1;
    }

    fn evict_from_recent(&mut self, _k: &K) {
        self.recent_evicts += 1;
    }

Without that, I am not sure how the counters are available... I see how they printed during the execution though

    fn include(&mut self, k: &K) {
        tracing::trace!(?k, "include");
    }
...

[Firstyear]

Check the trait: https://docs.rs/concread/latest/concread/arcache/stats/trait.ARCacheWriteStat.html and the Read equivalent.

So the "lazy" option is call read_stats() with https://docs.rs/concread/latest/concread/arcache/stats/struct.ReadCountStat.html and at the end of the transaction you call https://docs.rs/concread/latest/concread/arcache/struct.ARCacheReadTxn.html#method.finish which returns your stat counter and you can pull out the values you want. Similar for the Write version.

All of this is handled because those implement ARCache[Read|Write]Stat when you start a transaction ( https://docs.rs/concread/latest/concread/arcache/struct.ARCache.html#method.write_stats ) and they track those events that you want. So every you need is there.

Alternately, you can recreate these structs by implementing the ARCache[Read|Write]Stat for your own stat struct, and just track the precise events you want to track such as https://docs.rs/concread/latest/concread/arcache/stats/trait.ARCacheWriteStat.html#method.include includes, https://docs.rs/concread/latest/concread/arcache/stats/trait.ARCacheWriteStat.html#method.evict_from_frequent evicts etc.

The idea was that we wanted to split out the stats so that you could "create your own" based on your needs, because not everyone needs to track all those details. This way when you aren't tracking the stats, the tracking calls are dead code eliminated.

[droideck]

Thanks for the detailed explanation!!
So, after some diving into concread, that's what I found:

From what I can see, there's an interesting difference between read_stats and write_stats:

• read_stats only return increments once when called after transaction's finish)
• Meanwhile, write_stats -> commit returns cache-deived values (calculated from len):
  • shared_max
  • freq
  • recent
  • p_weight
  • all_seen_keys

I've attempted to implement tracking for evictions and modify/include operations but haven't succeeded yet (though I might be missing something obvious! When you have time, please, check my PR 389ds/389-ds-base#6607 ).

And even if I'll succeed with the implementation. I wonder if we could track eviction/modify/include counts in the same direct way we currently track shared_max, freq, recent, etc.? It would be really useful to have these metrics readily available without an additional dance... They shouldn't take up too much space, IIUC.
Alternatively, perhaps we could make them accessible in a similar fashion to how read stats work? (I'm not sure what'll be more convenient)

[Firstyear]

Thanks for the detailed explanation!! So, after some diving into concread, that's what I found:

From what I can see, there's an interesting difference between read_stats and write_stats:

* `read_stats` only return increments once when called after transaction's `finish`)

Part of this difference is that a read transaction normally is dropped (freed) after use, so finish is just a drop and return stats handler. There is no state to commit or change.

* Meanwhile, `write_stats` -> `commit` returns cache-deived values (calculated from `len`):
  
  * shared_max
  * freq
  * recent
  * p_weight
  * all_seen_keys

However in a write transaction, if you abort the transaction, no changes occur to the cache, so it's stats don't change.

I've attempted to implement tracking for evictions and modify/include operations but haven't succeeded yet (though I might be missing something obvious! When you have time, please, check my PR 389ds/389-ds-base#6607 ).

You need to disable automatic quiesece and then after you call .finish() on a read, you call https://docs.rs/concread/latest/concread/arcache/struct.ARCache.html#method.try_quiesce_stats to then get the other stats back.

And even if I'll succeed with the implementation. I wonder if we could track eviction/modify/include counts in the same direct way we currently track shared_max, freq, recent, etc.? It would be really useful to have these metrics readily available without an additional dance... They shouldn't take up too much space, IIUC. Alternatively, perhaps we could make them accessible in a similar fashion to how read stats work? (I'm not sure what'll be more convenient)

Not so easy :) you need to do the quiesce above to get to those values.