On Tue, 21 Aug 2007, Mathieu Desnoyers wrote: > - Fixed an erroneous test in slab_free() (logic was flipped from the > original code when testing for slow path. It explains the wrong > numbers you have with big free).
If you look at the numbers that I posted earlier then you will see that even the measurements without free were not up to par. > It applies on top of the > "SLUB Use cmpxchg() everywhere" patch. Which one is that? > | slab.git HEAD slub (min-max) | cmpxchg_local slub > kmalloc(8) | 190 - 201 | 83 > kfree(8) | 351 - 351 | 363 > kmalloc(64) | 224 - 245 | 115 > kfree(64) | 389 - 394 | 397 > kmalloc(16384)| 713 - 741 | 724 > kfree(16384) | 843 - 856 | 843 > > Therefore, there seems to be a repeatable gain on the kmalloc fast path > (more than twice faster). No significant performance hit for the kfree > case, but no gain neither, same for large kmalloc, as expected. There is a consistent loss on slab_free it seems. The 16k numbers are irrelevant since we do not use slab_alloc/slab_free due to the direct pass through patch but call the page allocator directly. That also explains that there is no loss there. The kmalloc numbers look encouraging. I will check to see if I can reproduce it once I sort out the patches. - 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/
