Hi Chris, Replies inline ...
On Thu, Nov 8, 2018 at 8:45 PM Christopher Collins <ch...@runtime.io> wrote: > I agree this would be a very useful feature. Did you end up > investigating this? I have written some of my thoughts on the subject > below. All comments welcome. > I haven't explored the idea further, no. I had to move onto config settings and driver improvements with the delivery date for the project. > > I. What gets persisted - individual stats, or entire stat modules? > 1. Individual stats: we waste flash by including the module name in > every record. > > 2. Entire stat modules - two options: > a. Waste flash persisting unchanged stats, or > > b. Need to to remember which stats have changed since the last > time the module was persisted. This allows us to only > persist stats whose values have changed. > > I think option 2b is the best. There is some implementation effort, but > the savings in flash usage is worth it, in my opinion. > I agree saving the entire block makes the most sense, with a check against the last persisted dataset before writing. > > II. When do we persist? > > There are a few options. I think the most flexible option is: give each > stat module a timer and a configurable "delay". When a stat changes, > schedule the module's timer to expire after its configured delay (only > if the timer isn't already scheduled). When the timer expires, the > module gets persisted. > > If the user wants stats to be persisted immediately each time they > change, the user can configure their stats modules with a delay of 0. > For less important stats, a much larger delay can be used. > I don't have a strong opinion here, but this seems sensible and '0' as an option avoids and potential constraints. > > III. Implementation > > 1. Add a timer to each stats module. > > A bit from the new `s_flags` field could indicate whether the stats > module is "classic" or "persisted". > This also seems sensible to me without breaking the current struct or drivers. > 2. Remember which stats have changed since being persisted. > > Each stat needs a "dirty bit." There are two ways to do this: > a. Hijack the most-significant-bit of each stat. > b. Maintain dirty state in a separate bitmap in the stats module. > > Option a has some issues: > * We lose half the range of each stat. > * Looking at these stats in gdb will be quite confusing. > Yeah, this is less obvious or ideal. I agree that using the MSB is annoying for debugging, etc., and messy. But both options have issues. I'd say 'a', but neither is great. :( For the MSB approach, at least the values aren't signed which simplifies things and 2B is still a fairly large range. Speaking of numeric limits ... another consideration persisting data is should we persist a rollover counter, and if so ... how and where? Kevin
