Re: io_uring_prep_openat_direct() and link/drain

[Jens Axboe <axboe@kernel.dk>]

On 4/5/22 1:45 AM, Miklos Szeredi wrote:
> On Sat, 2 Apr 2022 at 03:17, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 4/1/22 10:21 AM, Jens Axboe wrote:
>>> On 4/1/22 10:02 AM, Miklos Szeredi wrote:
>>>> On Fri, 1 Apr 2022 at 17:36, Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>>> I take it you're continually reusing those slots?
>>>>
>>>> Yes.
>>>>
>>>>>  If you have a test
>>>>> case that'd be ideal. Agree that it sounds like we just need an
>>>>> appropriate breather to allow fput/task_work to run. Or it could be the
>>>>> deferral free of the fixed slot.
>>>>
>>>> Adding a breather could make the worst case latency be large.  I think
>>>> doing the fput synchronously would be better in general.
>>>
>>> fput() isn't sync, it'll just offload to task_work. There are some
>>> dependencies there that would need to be checked. But we'll find a way
>>> to deal with it.
>>>
>>>> I test this on an VM with 8G of memory and run the following:
>>>>
>>>> ./forkbomb 14 &
>>>> # wait till 16k processes are forked
>>>> for i in `seq 1 100`; do ./procreads u; done
>>>>
>>>> You can compare performance with plain reads (./procreads p), the
>>>> other tests don't work on public kernels.
>>>
>>> OK, I'll check up on this, but probably won't have time to do so before
>>> early next week.
>>
>> Can you try with this patch? It's not complete yet, there's actually a
>> bunch of things we can do to improve the direct descriptor case. But
>> this one is easy enough to pull off, and I think it'll fix your OOM
>> case. Not a proposed patch, but it'll prove the theory.
> 
> Sorry for the delay..
> 
> Patch works like charm.

OK good, then it is the issue I suspected. Thanks for testing!

-- 
Jens Axboe