From: Mala Anand <mkanand@us.ibm.com>
Date: Wed, 16 Oct 2002 16:15:41 -0500
Looks like we were trying to take advantage of this feature by
initializing before freeing it and this is good for UNI but for SMP
there is no guarantee that the freed skbs will be given back to the
same CPU.
There are not guarentees, but %99 of the time what is supposed to
happen is that either the per-cpu skb_head_pool[] or the per-cpu slab
cache give back the data on the same processor.
If this isn't happening, fix the head pool or SLAB. Because if
you fix it there you'll fix the SMP behavior of every other SLAB
cache in the kernel, not just SKBs.
If the current cpu's skb_head_pool[] is being depleted in your
tests, it should go to the per-cpu SLAB pool, if that is being
depleted and thus it is going to other cpu's pools you should
work on making SLAB not hit that case so often.
2.5.38 is really old too, results with current 2.5.x would be
appreciated. If you are unable to run your tests with current
2.5.x kernels, work to fix those problems instead of telling me
"I can't test with current 2.5.x"
Also, I would really appreciate it if you could walk through the
2.5.x versions between the "good" and "bad" performance points
you noted in postings yesterday. Please do not walk off to other
tasks such as this SKB initialization patch when we have regressions
in other areas.
-
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/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:30 EST