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

[Jens Axboe <axboe@kernel.dk>]

On 1/23/25 8:05 AM, Pavel Begunkov wrote:
> 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?

We obviously could, but rw/net is 2-300b in size, and most of it we
don't need to clear. Yes this is only for the "slower" path of hitting
alloc rather than the cache, but it's not a given at all that any
workload will fit within the cache, unfortunately. That's quite a lot of
memset for those cases.

But maybe I'm overdoing it and we just kzalloc() it. It'd obviously be a
lot simpler.

-- 
Jens Axboe