On 6/17/24 8:42 PM, Uladzislau Rezki wrote: >> + >> + s = container_of(work, struct kmem_cache, async_destroy_work); >> + >> + // XXX use the real kmem_cache_free_barrier() or similar thing here > It implies that we need to introduce kfree_rcu_barrier(), a new API, which i > wanted to avoid initially. I wanted to avoid new API or flags for kfree_rcu() users and this would be achieved. The barrier is used internally so I don't consider that an API to avoid. How difficult is the implementation is another question, depending on how the current batching works. Once (if) we have sheaves proven to work and move kfree_rcu() fully into SLUB, the barrier might also look different and hopefully easier. So maybe it's not worth to invest too much into that barrier and just go for the potentially longer, but easier to implement? > Since you do it asynchronous can we just repeat > and wait until it a cache is furry freed? The problem is we want to detect the cases when it's not fully freed because there was an actual read. So at some point we'd need to stop the repeats because we know there can no longer be any kfree_rcu()'s in flight since the kmem_cache_destroy() was called. > I am asking because inventing a new kfree_rcu_barrier() might not be so > straight forward. Agreed. > > -- > Uladzislau Rezki
