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. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
