On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> With __kmem_cache_free you would set #1 I hope, but if
> nobody would use this - debugging time wouldn't change.
I think you got it backwards. I suggested making the _current_
kmem_cache_free() deal with NULL (so everyone will get it) and add a new
optimized __kmem_cache_free() for those call-sites that really need it.
On Wed, 21 Mar 2007, Jarek Poplawski wrote:
> This could be acceptable, if there were no problems
> with fixing the errors. But there are problems - bugs
> like this aren't fixed on time - maybe because people
> waste too much time per bug?
You're barking up the wrong tree here, Jarek. I strongly feel that we
should be more defensive in the slab for the exact reasons you outlined.
There's bunch of bug reports people seem to dismiss as slab errors where
in fact it's caused by a buggy caller.
That said, Eric and Andrew make a good point about kmem_cache_free() being
in super-hot paths which clearly must be addressed. The only reason
holding me back is the fact that I don't know what those super-hot
call-sites are (with the exception of network skb allocation) so I am
really in no position to make that patch.
Pekka
-
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/
