On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > There's an extremely small overhead of taking this lock, the cache has
> > been destroyed and is the process of being torn down, there will be
> > absolutely no contention on n->list_lock.
>
> But why add it if it isn't necessary? You're even disabling interrupts,
> which means that you add to the response latency. That is, this change
> does affect other aspects of the kernel!
>
The functions that manipulate the partial lists was modified by
c65c1877bd68 ("slub: use lockdep_assert_held") which replaced commentary
with runtime checking on debug kernels with lockdep enabled. I'm not sure
adding more code to do the remove_partial() and __remove_partial() variant
is the right solution to just bypass the check; if anything, I think we
should accept the fact that the comment should have been "requires
n->list_lock if the slab cache can be accessed by other cpus" that makes
it clear we don't need it for init and destroy paths.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
