Re: [RFC PATCH 2/2] slab: implement bulk free in SLAB allocator

From: Christoph Lameter <cl@linux.com>
To: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
	linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 2/2] slab: implement bulk free in SLAB allocator
Date: Tue, 8 Dec 2015 09:32:32 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1512080930290.21190@east.gentwo.org> (raw)
In-Reply-To: <20151208145635.GI11488@esperanza>

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>