From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 467CEC2BA19 for ; Sun, 12 Apr 2020 02:07:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 162A520753 for ; Sun, 12 Apr 2020 02:07:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="xuINY7C+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726689AbgDLCHo (ORCPT ); Sat, 11 Apr 2020 22:07:44 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:43435 "EHLO mail-pl1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726155AbgDLCHo (ORCPT ); Sat, 11 Apr 2020 22:07:44 -0400 Received: by mail-pl1-f179.google.com with SMTP id z6so2119790plk.10 for ; Sat, 11 Apr 2020 19:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MJkeVaCjtJEc3yNw921FlHG88krDP9fP/xlRD6YHEgI=; b=xuINY7C+MXIl42ypNiwBGJVta6Zd2g1HMsHMKIl4bk9drYEfpY9odLtKZ0PvWRi5UJ qwH+vsnO4JsQzQveVtzdp8noNR5wQbs5FFnGzZspnPCQ4YkASXR9UNH6nBfAjSKTAFjh HmSWIlwP6HtcDyCYAZfb4OW+4eXlW2wi5wekq57WSOgko8E45Mv2btaWuF4Y5sc4GEnM 9KGGjM3bUkta12jq6IS8qFfM0acPqcSi5GwkLS4897m2QgXhOpFR2wqPMDqHNcd43X+9 g+ci4kx4/TEhMY6YIBJNhJ+c3um3aNiyzedVO82Uh6WqRLC/Fr5dCU/Q7mgbTxHObtk5 fJwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MJkeVaCjtJEc3yNw921FlHG88krDP9fP/xlRD6YHEgI=; b=C5KUzs2t5s/d4Q7zrp6XovSEANccQjFOVNyAICN4L9OJJDHKoGybNJWsCrbhg1YiNh SUgXx6tI/hCa1j1ORKRk0Cd1oIt25sI29UWlEDSDwWLWwHc9659Om7H2K+Hmm5oPStHg YAh4XTusOL0fzgRKjjw69e6aX9qMfoKE6SnfOTF/FJjOwkVsF4rSMMqtxcPkKAwTs4W4 b/w39QXY/WJqAvuvzwWyclIv7DhE1PoUlYIiGh2SDjLTqNCRejKhPM4S5fTDC+jNtBKb htl+osYM+VmepADWS3CY2Nj3dcPn11ViVPHqbt7+pwsJjuB1xfoATiSD0+gkANS0dJ0P BjDA== X-Gm-Message-State: AGi0PuZQLRPi5Y5ZYvopCUstVIM5W188dw8xQVKoEOIaZkDc2pMjoPYC Ns3cbMlTB8IrV7R94Ch/yemQvA== X-Google-Smtp-Source: APiQypLWV82UyC+m1c6rdDcXZVPNIZHo/sNDh7vxcs2xHYU5DWCXLxlujw0msB61IiXnNnysCnb8bg== X-Received: by 2002:a17:90a:1a10:: with SMTP id 16mr14582853pjk.31.1586657263340; Sat, 11 Apr 2020 19:07:43 -0700 (PDT) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id u26sm4678379pga.3.2020.04.11.19.07.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Apr 2020 19:07:42 -0700 (PDT) Subject: Re: Odd timeout behavior To: Hrvoje Zeba , io-uring@vger.kernel.org, Pavel Begunkov , "zhangyi (F)" References: From: Jens Axboe Message-ID: Date: Sat, 11 Apr 2020 20:07:41 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org 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. Adding Pavel and Yi Zhang. -- Jens Axboe