On Mon, Aug 22, 2022 at 12:00:03PM -0700, Darrick J. Wong wrote: > On Wed, Aug 10, 2022 at 09:03:47AM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Currently the AIL attempts to keep 25% of the "log space" free, > > where the current used space is tracked by the reserve grant head. > > That is, it tracks both physical space used plus the amount reserved > > by transactions in progress. > > > > When we start tail pushing, we are trying to make space for new > > reservations by writing back older metadata and the log is generally > > physically full of dirty metadata, and reservations for modifications > > in flight take up whatever space the AIL can physically free up. > > > > Hence we don't really need to take into account the reservation > > space that has been used - we just need to keep the log tail moving > > as fast as we can to free up space for more reservations to be made. > > We know exactly how much physical space the journal is consuming in > > the AIL (i.e. max LSN - min LSN) so we can base push thresholds > > directly on this state rather than have to look at grant head > > reservations to determine how much to physically push out of the > > log. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > Makes sense, I think. Though I was wondering about the last patch -- > pushing the AIL until it's empty when a trans_alloc can't find grant > reservation could take a while on a slow storage. The push in the grant reservation code is not a blocking push - it just tells the AIL to start pushing everything, then it goes to sleep waiting for the tail to move and space to come available. The AIL behaviour is largely unchanged, especially if the application is running under even slight memory pressure as the inode shrinker will repeatedly kick the AIL push-all trigger regardless of consumed journal/grant space. > Does this mean that > we're trading the incremental freeing-up of the existing code for > potentially higher transaction allocation latency in the hopes that more > threads can get reservation? Or does the "keep the AIL going" bits make > up for that? So far I've typically measured slightly lower worst case latencies with this mechanism that with the existing "repeatedly push to 25% free" that we currently have. It's not really significant enough to make statements about (unlike cpu usage reductions or perf increases), but it does seem to be a bit better... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
