public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Hrvoje Zeba <[email protected]>
Cc: Jens Axboe <[email protected]>,
	[email protected], "zhangyi (F)" <[email protected]>
Subject: Re: Odd timeout behavior
Date: Mon, 13 Apr 2020 11:21:25 +0300	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEsUgYiwyjpbaUbHwbx9pHD6x5DBpDop_Z4w9_QXKDd=FdjDjw@mail.gmail.com>

On 4/12/2020 6:14 PM, Hrvoje Zeba wrote:
> On Sun, Apr 12, 2020 at 5:15 AM Pavel Begunkov <[email protected]> wrote:
>>
>> On 4/12/2020 5:07 AM, Jens Axboe wrote:
>>> On 4/11/20 5:00 PM, Hrvoje Zeba wrote:
>>>> Hi,
>>>>
>>>> I've been looking at timeouts and found a case I can't wrap my head around.
>>>>
>>>> Basically, If you submit OPs in a certain order, timeout fires before
>>>> time elapses where I wouldn't expect it to. The order is as follows:
>>>>
>>>> poll(listen_socket, POLLIN) <- this never fires
>>>> nop(async)
>>>> timeout(1s, count=X)
>>>>
>>>> If you set X to anything but 0xffffffff/(unsigned)-1, the timeout does
>>>> not fire (at least not immediately). This is expected apart from maybe
>>>> setting X=1 which would potentially allow the timeout to fire if nop
>>>> executes after the timeout is setup.
>>>>
>>>> If you set it to 0xffffffff, it will always fire (at least on my
>>>> machine). Test program I'm using is attached.
>>>>
>>>> The funny thing is that, if you remove the poll, timeout will not fire.
>>>>
>>>> I'm using Linus' tree (v5.6-12604-gab6f762f0f53).
>>>>
>>>> Could anybody shine a bit of light here?
>>>
>>> Thinking about this, I think the mistake here is using the SQ side for
>>> the timeouts. Let's say you queue up N requests that are waiting, like
>>> the poll. Then you arm a timeout, it'll now be at N + count before it
>>> fires. We really should be using the CQ side for the timeouts.
>>
>> As I get it, the problem is that timeout(off=0xffffffff, 1s) fires
>> __immediately__ (i.e. not waiting 1s).
> 
> Correct.
> 
>> And still, the described behaviour is out of the definition. It's sounds
>> like int overflow. Ok, I'll debug it, rest assured. I already see a
>> couple of flaws anyway.
> 
> For this particular case,
> 
> req->sequence = ctx->cached_sq_head + count - 1;
> 
> ends up being 1 which triggers in __req_need_defer() for nop sq.

Right, that's it. The timeout's seq counter wraps around and triggers on
previously submitted but still inflight requests.

Jens, could you remind, do we limit number of inflight requests? We
discussed it before, but can't find the thread. If we don't, vile stuff
can happen with sequences.

-- 
Pavel Begunkov

  reply	other threads:[~2020-04-13  8:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11 23:00 Odd timeout behavior Hrvoje Zeba
2020-04-12  2:07 ` Jens Axboe
2020-04-12  9:15   ` Pavel Begunkov
2020-04-12 14:40     ` Jens Axboe
2020-04-17  8:39       ` Pavel Begunkov
2020-04-17 14:37         ` Hrvoje Zeba
2020-04-12 15:14     ` Hrvoje Zeba
2020-04-13  8:21       ` Pavel Begunkov [this message]
2020-04-13 14:16         ` Jens Axboe
2020-04-13 19:09           ` Pavel Begunkov
2020-04-14  0:44             ` Jens Axboe
2020-04-14 15:46               ` Pavel Begunkov
2020-04-14 16:04                 ` Jens Axboe
2020-04-14 16:31                   ` Pavel Begunkov

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] \
    [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