On Wed, Mar 10, 2021 at 07:06:36PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > Split the inode inactivation work into per-AG work items so that we can > take advantage of parallelization. How does this scale out when we have thousands of AGs? I'm guessing that the gc_workqueue has the default "unbound" parallelism that means it will run up to 4 kworkers per CPU at a time? Which means we could have hundreds of ags trying to hammer on inactivations at the same time? And so bash hard on the log and completely starve the syscall front end of log space? It seems to me that this needs to bound the amount of concurrent work to quite low numbers - even though it is per-ag, we do not want this to swamp the system in kworkers blocked on log reservations when such concurrency it not necessary. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
