Re: [PATCH 2/2] io_uring: get rid of alloc cache init_once handling

[Pavel Begunkov <asml.silence@gmail.com>]

On 1/23/25 14:55, Jens Axboe wrote:
> On 1/23/25 7:47 AM, Pavel Begunkov wrote:
>> On 1/23/25 14:27, Pavel Begunkov wrote:
>>> On 1/23/25 14:21, Jens Axboe wrote:
>>>> init_once is called when an object doesn't come from the cache, and
>>>> hence needs initial clearing of certain members. While the whole
>>>> struct could get cleared by memset() in that case, a few of the cache
>>>> members are large enough that this may cause unnecessary overhead if
>>>> the caches used aren't large enough to satisfy the workload. For those
>>>> cases, some churn of kmalloc+kfree is to be expected.
>>>>
>>>> Ensure that the 3 users that need clearing put the members they need
>>>> cleared at the start of the struct, and place an empty placeholder
>>>> 'init' member so that the cache initialization knows how much to
>>>> clear.
>>>>
>>>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>>>> ---
>>>>    include/linux/io_uring/cmd.h   |  3 ++-
>>>>    include/linux/io_uring_types.h |  3 ++-
>>>>    io_uring/alloc_cache.h         | 30 +++++++++++++++++++++---------
>>>>    io_uring/futex.c               |  4 ++--
>>>>    io_uring/io_uring.c            | 13 ++++++++-----
>>>>    io_uring/io_uring.h            |  5 ++---
>>>>    io_uring/net.c                 | 11 +----------
>>>>    io_uring/net.h                 |  7 +++++--
>>>>    io_uring/poll.c                |  2 +-
>>>>    io_uring/rw.c                  | 10 +---------
>>>>    io_uring/rw.h                  |  5 ++++-
>>>>    io_uring/uring_cmd.c           | 10 +---------
>>>>    12 files changed, 50 insertions(+), 53 deletions(-)
>>>>
>>>> diff --git a/include/linux/io_uring/cmd.h b/include/linux/io_uring/cmd.h
>>>> index a3ce553413de..8d7746d9fd23 100644
>>>> --- a/include/linux/io_uring/cmd.h
>>>> +++ b/include/linux/io_uring/cmd.h
>>>> @@ -19,8 +19,9 @@ struct io_uring_cmd {
>>>>    };
>>>>    struct io_uring_cmd_data {
>>>> -    struct io_uring_sqe    sqes[2];
>>>>        void            *op_data;
>>>> +    int            init[0];
>>>
>>> What do you think about using struct_group instead?
>>
>> And why do we care not clearing it all on initial alloc? If that's
>> because of kasan, we can disable it until ("kasan, mempool: don't
>> store free stacktrace in io_alloc_cache objects") lands.
> 
> Not sure I follow - on initial alloc they do need clearing, that's when
> they need clearing. If they are coming from the cache, the state should
> be consistent.

If we forget about kasan, ->init_clear is only really used right
after allocation().

+	obj = kmalloc(cache->elem_size, gfp);
+	if (obj && cache->init_clear)
+		memset(obj, 0, cache->init_clear);

Why not kzalloc() it?

-- 
Pavel Begunkov