All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Xu <hao.xu@linux.dev>
To: Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH for-next] io_uring: let to set a range for file slot allocation
Date: Wed, 29 Jun 2022 20:29:09 +0800	[thread overview]
Message-ID: <53f823a3-6878-9249-5f6c-f049e4d2b0df@linux.dev> (raw)
In-Reply-To: <a20e307a-6a7e-dca4-7ec6-e630fa17a0e5@gmail.com>

On 6/29/22 20:18, Pavel Begunkov wrote:
> On 6/27/22 08:47, Hao Xu wrote:
>> On 6/25/22 18:55, Pavel Begunkov wrote:
>>>  From recently io_uring provides an option to allocate a file index for
>>> operation registering fixed files. However, it's utterly unusable with
>>> mixed approaches when for a part of files the userspace knows better
>>> where to place it, as it may race and users don't have any sane way to
>>> pick a slot and hoping it will not be taken.
>>
>> Exactly, with high frequency of index allocation from like multishot
>> accept, it's easy that user-pick requests fails.
>> By the way, just curious, I can't recall a reason that users pick a slot
>> rather than letting kernel do the decision, is there any? So I guess
> 
> Can't say for the initial design, but I prefer to give away control
> over such stuff to the userspace 1) to not over pollute the kernel
> (not relevant anymore), 2) because it has more knowledge and can
> use it more efficiently. E.g. to have O(1) memory and search time
> by using in-place index based free slot list, when indexes can be
> contants, and so on.
> 

Yea, I knew. Leave it alone to userspace makes biggest flexibility.

> 
>> users may use all the indexes as 'file slot allocation' range. Correct
>> me if I miss something.
> 
> Yeah, can be enough, and that's what the range is set to by default.
> 
>>> Let the userspace to register a range of fixed file slots in which the
>>> auto-allocation happens. The use case is splittting the fixed table in
>>> two parts, where on of them is used for auto-allocation and another for
>>> slot-specified operations.
>>>
>>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
>>> ---
> [...]
>>> @@ -24,11 +24,10 @@ static int io_file_bitmap_get(struct io_ring_ctx 
>>> *ctx)
>>>           if (ret != nr)
>>>               return ret;
>>> -        if (!table->alloc_hint)
>>> +        if (table->alloc_hint == ctx->file_alloc_start)
>>>               break;
>>> -
>>>           nr = table->alloc_hint;
>>> -        table->alloc_hint = 0;
>>> +        table->alloc_hint = ctx->file_alloc_start;
>>
>> should we use io_reset_alloc_hint() ?
> 
> We could but I'd rather prefer not. It's used just to anything valid
> within the range, while in io_file_bitmap_get() it's specifically to
> wrap around.
> 


  reply	other threads:[~2022-06-29 12:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-25 10:55 [PATCH for-next] io_uring: let to set a range for file slot allocation Pavel Begunkov
2022-06-25 13:08 ` Jens Axboe
2022-06-27  7:47 ` Hao Xu
2022-06-29 12:18   ` Pavel Begunkov
2022-06-29 12:29     ` Hao Xu [this message]
2022-06-29 17:02 ` Jens Axboe
2022-06-29 17:02 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53f823a3-6878-9249-5f6c-f049e4d2b0df@linux.dev \
    --to=hao.xu@linux.dev \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.