public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Hao Xu <[email protected]>, [email protected]
Cc: Jens Axboe <[email protected]>
Subject: Re: [PATCH for-next] io_uring: let to set a range for file slot allocation
Date: Wed, 29 Jun 2022 13:18:58 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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.


> 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 <[email protected]>
>> ---
[...]
>> @@ -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.

-- 
Pavel Begunkov

  reply	other threads:[~2022-06-29 12:22 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 [this message]
2022-06-29 12:29     ` Hao Xu
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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox