On Tue, Jun 18, 2024 at 09:48:49AM -0700, Paul E. McKenney wrote: > On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote: > > > 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? > > > > > Right. I agree here. If the cache is not empty, OK, we just defer the > > work, even we can use a big 21 seconds delay, after that we just "warn" > > if it is still not empty and leave it as it is, i.e. emit a warning and > > we are done. > > > > Destroying the cache is not something that must happen right away. > > OK, I have to ask... > > Suppose that the cache is created and destroyed by a module and > init/cleanup time, respectively. Suppose that this module is rmmod'ed > then very quickly insmod'ed. > > Do we need to fail the insmod if the kmem_cache has not yet been fully > cleaned up? If not, do we have two versions of the same kmem_cache in > /proc during the overlap time? > No fail :) If same cache is created several times, its s->refcount gets increased, so, it does not create two entries in the "slabinfo". But i agree that your point is good! We need to be carefully with removing and simultaneous creating.
