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@xxxxxxxxx>
>>>>> ---
>>>>> 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
