On Sat, Oct 26, 2024 at 10:08 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > On Fri, 25 Oct 2024, Yang Shi wrote: > > > > The other subtle thing is folio->_deferred_list is reused when the > > folio is moved to the local on-stack list. And some > > Yes. > > > list_empty(deferred_list) checks return true even though the folio is > > actually on the local on-stack list. Some code may depend on or > > The code definitely depends on that behaviour: that's how folios get > unqueued when refcount reaches 0, whether they are on the public list > or on the local list at that time. Yeah, folio may have 0 refcount on the local list after that folio_put() before it is moved back to deferred list. The main purpose for using folio_batch is to disambiguate list_empty() so that we don't rely on this subtle behavior. But I soon realized this may make deferred list lock contention worse when moving the folios back to deferred list. Currently we just need to do list splice, but we have to add every single folio back to deferred list one by one with folio_batch. It depends on how often folio split fails. > > > inadvertently depend on this behavior. Using folio_batch may break > > some assumptions, but depending on this subtle behavior is definitely > > not reliable IMHO.
