On Tue, 8 Dec 2015, Vladimir Davydov wrote: > Don't think so, because AFAIU the whole kmem_cache_free_bulk > optimization comes from the assumption that objects passed to it are > likely to share the same slab page. So they must be of the same kind, > otherwise no optimization would be possible and the function wouldn't > perform any better than calling kfree directly in a for-loop. By > requiring the caller to specify the cache we emphasize this. This is likely but an implementation specific feature that only SLUB can exploit. However, one page can only contain objects from the same slab page. So checking the slab cache too is irrelevant. We could take it out. If the logic finds two objects that share the same page then they will be from the same slab cache. The checking of the cache is just not necessary and actually increases the code size and therefore reduces performance. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>