Messages in this thread | | | Date | Thu, 03 Sep 2009 17:02:10 +0200 | From | Eric Dumazet <> | Subject | Re: [PATCH] slub: fix slab_pad_check() |
| |
Christoph Lameter a écrit : > On Thu, 3 Sep 2009, Eric Dumazet wrote: > >> Christoph Lameter a ?crit : >>> On Thu, 3 Sep 2009, Eric Dumazet wrote: >>> >>>> on a SLAB_DESTROY_BY_RCU cache, there is no need to try to optimize this >>>> rcu_barrier() call, unless we want superfast reboot/halt sequences... >>> I stilll think that the action to quiesce rcu is something that the caller >>> of kmem_cache_destroy must take care of. >> Do you mean : >> >> if (kmem_cache_shrink(s) == 0) { >> rcu_barrier(); >> kmem_cache_destroy_no_rcu_barrier(s); >> } else { >> kmem_cache_destroy_with_rcu_barrier_because_SLAB_DESTROY_BY_RCU_cache(s); >> } >> >> What would be the point ? > > The above is port of slub?
No, I am trying to code what you suggest, and I could not find a clean way with current API (SLAB/SLUB/SLOB)
> > I mean that (in this case) the net subsystem would have to deal with RCU quietness > before disposing of the slab cache. There may be multiple ways of dealing > with RCU. The RCU barrier may be unnecessary for future uses. Typically > one would expect that all deferred handling of structures must be complete > for correctness before disposing of the whole cache.
Point is we cannot deal with RCU quietness before disposing the slab cache, (if SLAB_DESTROY_BY_RCU was set on the cache) since this disposing *will* make call_rcu() calls when a full slab is freed/purged. And when RCU grace period is elapsed, the callback *will* need access to the cache we want to dismantle. Better to not have kfreed()/poisoned it...
I believe you mix two RCU uses here.
1) The one we all know, is use normal caches (!SLAB_DESTROY_BY_RCU) (or kmalloc()), and use call_rcu(... kfree_something)
In this case, you are 100% right that the subsystem itself has to call rcu_barrier() (or respect whatever self-synchro) itself, before calling kmem_cache_destroy()
2) The SLAB_DESTROY_BY_RCU one.
Part of cache dismantle needs to call rcu_barrier() itself. Caller doesnt have to use rcu_barrier(). It would be a waste of time, as kmem_cache_destroy() will refill rcu wait queues with its own stuff.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |