On 6/8/22 8:23 PM, Christoph Lameter wrote:
On Wed, 8 Jun 2022, Rongwei Wang wrote:
If available, I think document the issue and warn this incorrect behavior is
OK. But it still prints a large amount of confusing messages, and disturbs us?
Correct it would be great if you could fix this in a way that does not
impact performance.
are current operations on the slab being validated.
And I am trying to fix it in following way. In a short, these changes only
works under the slub debug mode, and not affects the normal mode (I'm not
sure). It looks not elegant enough. And if all approve of this way, I can
submit the next version.
Anyway, thanks for your time:).
-wrw
@@ -3304,7 +3300,7 @@ static void __slab_free(struct kmem_cache *s,
struct
slab *slab,
{
void *prior;
- int was_frozen;
+ int was_frozen, to_take_off = 0;
struct slab new;
to_take_off has the role of !n ? Why is that needed?
- do {
- if (unlikely(n)) {
+ spin_lock_irqsave(&n->list_lock, flags);
+ ret = free_debug_processing(s, slab, head, tail, cnt, addr);
Ok so the idea is to take the lock only if kmem_cache_debug. That looks
ok. But it still adds a number of new branches etc to the free loop.
Some performance tests would be useful.
Hi Christoph
Thanks for your time!
Do you have some advice in benchmarks that need me to test? And I find
that hackbench and lkp was used frequently in mm/slub.c commits[1,2].
But I have no idea how to use these two benchmarks test to cover the
above changes. Can you give some examples? Thanks very much!
Sorry for late reply!
[1]https://lore.kernel.org/lkml/20210301080404.GF12822@xsang-OptiPlex-9020/
[2]https://lore.kernel.org/linux-mm/20210128134512.GF3592@xxxxxxxxxxxxxxxxxxx/
