On Tue, Dec 08, 2015 at 08:15:21AM -0600, Christoph Lameter wrote: > On Tue, 8 Dec 2015, Vladimir Davydov wrote: > > > If producers are represented by different processes, they can belong to > > different memory cgroups, so that objects passed to the consumer will > > come from different kmem caches (per memcg caches), although they are > > all of the same kind. This means, we must call cache_from_obj() on each > > object passed to kmem_cache_free_bulk() in order to free each object to > > the cache it was allocated from. > > The we should change the API so that we do not specify kmem_cache on bulk > free. Do it like kfree without any cache spec. > 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. Enabling kmemcg might break the assumption and neglect the benefit of using kmem_cache_free_bulk, but it is to be expected, because kmem accounting does not come for free. Callers who do care about the performance and count every cpu cycle will surely disable it, in which case cache_from_obj() will be a no-op and kmem_cache_free_bulk will bear fruit. Thanks, Vladimir -- 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>