Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp720229pxj; Thu, 10 Jun 2021 10:59:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzhIWpDn5In+CUIHkzKjz1qiIW5+hs1ef3v2Xf3lY50xR43iULNBxneKPwcQY50wvwKI46Q X-Received: by 2002:a17:906:c241:: with SMTP id bl1mr774079ejb.536.1623347956587; Thu, 10 Jun 2021 10:59:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623347956; cv=none; d=google.com; s=arc-20160816; b=DQr1AXdOFkwWUpbZBA9kbU9ljWcvqh9WS+BnSm5C++ETjQJkW9brYJr46TCSCu66pS nUGNVXTLpAuRGOkRCfiSIDkl8ZYLPWuF1v6aVdS5yxNc9wQa4ELmFpMslWyzYRHOLYEi VpyzjvoHvZi/Bdp0I8pH+KFxB8X9u5hKGEGMUS6TqDCmzmUeCYFoLGZgAqrGuq6yqbFo Q0QUvL3oyWOMgdisWDbfwy418GZJWSuwBZWm79EE0iMKmkbedp0wI1ZZpPTIFHpZvT7n tWfvQCytoThwr3F0/MgJxipRowlxAoQSfmxaPjVShhpVpU29nhMVW7mK4VcqM9Xt4umB RCPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:to:from:subject :message-id; bh=uaU0MiOtK4gpDGgE4VRxHazhzxX6Jo8p07reCIG7YyE=; b=KR9RJ576UL2T9ZEJ0Rw2UhebTTZI/0q4GFbHRjw/lbF23RnXQhc9XEKXnc8rvQpQRs VaMs65eVE32WAClPtdhY6IhsXtnlezJFJhpNVXcesRaIKZkDG4IALFaNqeZwPJMa7d/h P2QZDW1M3yHI2U1Eflx6ZiuYYJlg8pFd0iH49X9GO+o9sh1IIssY1+fvOdmkW6Tlj8hX v0jEhpqSdnWrUuWtWOdi3KFurfep3h+tk5my1WpRA32+HxpxP+J/3FMYn2ZWZake2dp3 5wI1dB5YyqzeRjU61L7KXtf6j5sunUvN9zgSDGTXLhaSCqhpcxb+IYYUmMxnlPfnEz7n zSQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x26si2806742edq.494.2021.06.10.10.58.52; Thu, 10 Jun 2021 10:59:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbhFJR6x (ORCPT + 99 others); Thu, 10 Jun 2021 13:58:53 -0400 Received: from cloud48395.mywhc.ca ([173.209.37.211]:51810 "EHLO cloud48395.mywhc.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230410AbhFJR6x (ORCPT ); Thu, 10 Jun 2021 13:58:53 -0400 Received: from modemcable064.203-130-66.mc.videotron.ca ([66.130.203.64]:51978 helo=[192.168.1.179]) by cloud48395.mywhc.ca with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lrOvG-0000o2-5S; Thu, 10 Jun 2021 13:56:54 -0400 Message-ID: <9938f22a0bb09f344fa5c9c5c1b91f0d12e7566f.camel@trillion01.com> Subject: Re: [PATCH] io_uring: reduce latency by reissueing the operation From: Olivier Langlois To: Pavel Begunkov , Jens Axboe , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 10 Jun 2021 13:56:53 -0400 In-Reply-To: References: <60c13bec.1c69fb81.73967.f06dSMTPIN_ADDED_MISSING@mx.google.com> <84e42313-d738-fb19-c398-08a4ed0e0d9c@gmail.com> <4b5644bff43e072a98a19d7a5ca36bb5e11497ec.camel@trillion01.com> Organization: Trillion01 Inc Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.40.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud48395.mywhc.ca X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trillion01.com X-Get-Message-Sender-Via: cloud48395.mywhc.ca: authenticated_id: olivier@trillion01.com X-Authenticated-Sender: cloud48395.mywhc.ca: olivier@trillion01.com X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2021-06-10 at 16:51 +0100, Pavel Begunkov wrote: > Right, but it still stalls other requests and IIRC there are people > not liking the syscall already taking too long. Consider > io_req_task_queue(), adds more overhead but will delay execution > to the syscall exit. > > In any case, would be great to have numbers, e.g. to see if > io_req_task_queue() is good enough, how often your problem > takes places and how much it gives us. > I will get you more more data later but I did run a fast test that lasted 81 seconds with a single TCP connection. The # of times that the sqe got reissued is 57. I'll intrumentalize a bit the code to answer the following questions: 1. What is the ratio of reissued read sqe/total read sqe 2. Average exec time of __io_queue_sqe() for a read sqe when data is already available vs avg exec time when sqe is reissued 3. average exec time when the sqe is pushed to async when it could have been reissued. With that info, I think that we will be in better position to evaluate whether or not the patch is good or not. Can you think of other numbers that would be useful to know to evaluate the patch performance?