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

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe