On Fri, Feb 28, 2020 at 09:02:02AM -0500, Brian Foster wrote: > See my earlier comment around batching. Right now we only relog one item > at a time and the relog reservation is intended to be the max possible > reloggable item in the fs. This needs to increase to support some kind > of batching here, but I think the prospective reloggable items right now > (i.e. 2 or 3 different intent types) allows a fixed calculation size to > work well enough for our needs. > > Note that I think there's a whole separate ball of complexity we could > delve into if we wanted to support something like arbitrary, per-item > (set) relog tickets with different reservation values as opposed to one > global, fixed size ticket. That would require some association between > log items and tickets and perhaps other items covered by the same > ticket, etc., but would provide a much more generic mechanism. As it is, > I think that's hugely overkill for the current use cases, but maybe we > find a reason to evolve this into something like that down the road.. >From what I'm seeing, a generic, arbitrary relogging mechanism based on a reservation stealing concept similar to the CIL is going to be simpler, less invasive, easier to expand in future and more robust than this "limited scope" proposal. I'm firmly in the "do it right the first time" camp here... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
