The allocation paths that use alloc_cache duplicate the same code
pattern, sometimes in a quite convoluted way. Fold the allocation into
the cache code itself, making it just an allocator function, and keeping
the cache policy invisible to callers. Another justification for doing
this, beyond code simplicity, is that it makes it trivial to test the
impact of disabling the cache and using slab directly, which I've used
for slab improvement experiments.
One relevant detail is that this allocates zeroed memory. Rationale is
that it simplifies the handling of the embedded free_iov in some of the
cached objects, and the performance impact shouldn't be meaningful,
since we are supposed to be hitting the cache most of the time and the
allocation is already the slow path.
Signed-off-by: Gabriel Krisman Bertazi <krisman@xxxxxxx>
---
io_uring/alloc_cache.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/io_uring/alloc_cache.h b/io_uring/alloc_cache.h
index b7a38a2069cf..6b34e491a30a 100644
--- a/io_uring/alloc_cache.h
+++ b/io_uring/alloc_cache.h
@@ -30,6 +30,13 @@ static inline void *io_alloc_cache_get(struct io_alloc_cache *cache)
return NULL;
}
+static inline void *io_alloc_cache_alloc(struct io_alloc_cache *cache, gfp_t gfp)
+{
+ if (!cache->nr_cached)
+ return kzalloc(cache->elem_size, gfp);
+ return io_alloc_cache_get(cache);
+}
+
/* returns false if the cache was initialized properly */
static inline bool io_alloc_cache_init(struct io_alloc_cache *cache,
unsigned max_nr, size_t size)
--
2.47.0
