On Thu, Oct 17, 2019 at 03:57:29AM -0400, Brian Foster wrote: > On Thu, Oct 17, 2019 at 12:24:38PM +1100, Dave Chinner wrote: > > It's not a contention issue - there's real bugs if we don't order > > the locking correctly here. > > > > Is this patch fixing real bugs in the existing code or reducing > contention/blocking in the reclaim codepath? My understanding was the > latter, so thus I'm trying to make sure I follow how this blocking can > actually happen that this patch purports to address. The reasoning in my > comment above is basically how I followed the existing code as it > pertains to blocking in reclaim, and that is the scenario I was asking > about... Neither. It's a patch that simplifies and formalises the unreferenced inode lookup alogrithm. Previous patches change the way we isolate inodes for reclaim, opening up the opportunity to simplify the lookup/reclaim synchronisation and remove a race condition that that we've carried a workaround to avoid for 20+ years. Yes, it has the added bonus of removing a potential blocking point in reclaim, but hitting that blocking point it is pretty rare so it's not really a reduction in anything measurable. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
