Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7935593ybl; Thu, 16 Jan 2020 08:01:53 -0800 (PST) X-Google-Smtp-Source: APXvYqzQ4+BuFsEz4jhxFRJkJm5bVgDB6S8RQoekXOfaMS7v92lDDtT4xaEIkSin13bnySbtvHhJ X-Received: by 2002:a05:6830:1e11:: with SMTP id s17mr2426061otr.343.1579190513626; Thu, 16 Jan 2020 08:01:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579190513; cv=none; d=google.com; s=arc-20160816; b=FvVsE+PFxpuZRIMvSQ4Vv+xEbyhnINtkpdwDU4uxqATETCG/5Q1p4HKAZLXpEEhbaK QamACISvTZsRiAs6w3RTIN2CdnE92inXmjH6ENBX5rdUrkBfkqKdO+FxlxRfnDN3bdaV 5ksPWdYnkRs4xxmc/y1olrl9s9WBZfVOTQO6DwTtkYRhd8UfY6L7JS9lMJQrDwJWaaGt Gfszb8Svvpj1k47Y5kBUyJ7e/tLxrWf58mbiroWj+SEuVmb/ue2MRhsaETd0V1tozdQ/ 9d7sG8sYfW8NVYMl/L9qYT0JxaozD95k1G6ZlLvO4UvfzV3gVQuPEsMbZvrbP0N5IXZK yo7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=9JA64lSSGZhM2+AlaRyGX22gJ8cKrvAPGqj8KNteWAA=; b=Yw9NKzuNKXH7Q8e2r/wqumY/NrF/30cMhIMnz+2AK4tmn2RVhq4r7kRSorLaqJXBhd oD68o78WcsENPl0boUtzyVo7eeFeqTIj20IRJLoSWBuGMIOjd/DT/E88af7mXK7KeRs2 rkOvpg/Zjb0igGBIsygdU2oBReJ+7L3lLVQOHDK21VR5dWz3cSOOnWJDql3VaqlcKacv 7cl4xlbhmsRNSFGuMCTSvOFZsCP9uwCWxslUaLDplj3X8T49MVP09PJvsiOjl/B9nisq E+sdsoSHFgL/Scd77IR1aOE5cmPqUWWvY1KOOoXjppHYy7IhM4n26S/fHDsOG0dD7yqb wAPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=eBfQSPTl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t16si13463248otp.257.2020.01.16.08.01.41; Thu, 16 Jan 2020 08:01:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=eBfQSPTl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726981AbgAPQA1 (ORCPT + 99 others); Thu, 16 Jan 2020 11:00:27 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:40062 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726653AbgAPQA1 (ORCPT ); Thu, 16 Jan 2020 11:00:27 -0500 Received: by mail-io1-f66.google.com with SMTP id x1so22330434iop.7 for ; Thu, 16 Jan 2020 08:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9JA64lSSGZhM2+AlaRyGX22gJ8cKrvAPGqj8KNteWAA=; b=eBfQSPTl2scwswbOFhSakwoAF8PgLkNlYnC3C6QeLqCeox/H7wcY+SIlR+lNSUw42o WOIT5oBuVgYd+Y1OGGrbGJNKNmktZTmNXZ16cIQuyAPm4YWbbgoXZnpe06HrfjhZe4wh Jvjp4VXvd7d0e1EMKTINBcMvDAv1ptgp5VdEi5x2MQSm3xy5BAWpnG4nDc8SWGvlFXF0 09mWFcUSVHjoTgkHypCGBi7RfnLUUYN7U9ZoE3UVeSBmMhUBAUqOMOwjHSseREsHpuz5 yEpQvoDQq9aZOqAgUm/bE5JmNmhYThEmhhBzTgBD2xFEjKfYh2Rhaz0m+v9VGIkXZF7p qPRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9JA64lSSGZhM2+AlaRyGX22gJ8cKrvAPGqj8KNteWAA=; b=KdQp+0q/3+IfSCpEbp+qT0pLFN9Yoik9KMIk92o4x4YVYtxEWDjUbJZ8V8WcAcihs8 l1PTdue4XwGueJcy1MYz4sjbjmJS0MzvuBM4/N26LzRt3nJNmHCpCzLRvuSmjN7psa9w DfD7B3THBRWaC8sJWOa7/ovWHL0RELJQ5QcqqaauAn+dpVSfLq3I6zUnRv/FXvqO3kea q7M9pRzIvUp33sWHcXeATEPsrCtDUjxUXOr82a0c2vdvvBBPSWLoL0mbaFp+dTSBgjC7 fOwHBF/mfRSN/0SQcaiyIhjv5pRnVo9JFgPdrFk95DTSDMPbLvAq0IePgsas461ZYR4n KRPA== X-Gm-Message-State: APjAAAW8Frlp32ZD56JZeer36tR85MZEa9dXOVLzLVdO44/OjYw/zplK PnJYwtaNGsGCDMwGjvK51Wgh8A== X-Received: by 2002:a6b:740c:: with SMTP id s12mr28568449iog.108.1579190425642; Thu, 16 Jan 2020 08:00:25 -0800 (PST) Received: from [192.168.1.159] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id y14sm2002012ioa.12.2020.01.16.08.00.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 08:00:25 -0800 (PST) Subject: Re: [PATCH] io_uring: wakeup threads waiting for EPOLLOUT events To: Stefano Garzarella Cc: Alexander Viro , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20200116134946.184711-1-sgarzare@redhat.com> <2d2dda92-3c50-ee62-5ffe-0589d4c8fc0d@kernel.dk> <20200116155557.mwjc7vu33xespiag@steredhat> From: Jens Axboe Message-ID: <5723453a-9326-e954-978e-910b8b495b38@kernel.dk> Date: Thu, 16 Jan 2020 09:00:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200116155557.mwjc7vu33xespiag@steredhat> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/16/20 8:55 AM, Stefano Garzarella wrote: > On Thu, Jan 16, 2020 at 08:29:07AM -0700, Jens Axboe wrote: >> On 1/16/20 6:49 AM, Stefano Garzarella wrote: >>> io_uring_poll() sets EPOLLOUT flag if there is space in the >>> SQ ring, then we should wakeup threads waiting for EPOLLOUT >>> events when we expose the new SQ head to the userspace. >>> >>> Signed-off-by: Stefano Garzarella >>> --- >>> >>> Do you think is better to change the name of 'cq_wait' and 'cq_fasync'? >> >> I honestly think it'd be better to have separate waits for in/out poll, >> the below patch will introduce some unfortunate cacheline traffic >> between the submitter and completer side. > > Agree, make sense. I'll send a v2 with a new 'sq_wait'. > > About fasync, do you think could be useful the POLL_OUT support? > In this case, maybe is not simple to have two separate fasync_struct, > do you have any advice? The fasync should not matter, it's all in the checking of whether the sq side has any sleepers. This is rarely going to be the case, so as long as we can keep the check cheap, then I think we're fine. Since the use case is mostly single submitter, unless you're doing something funky or unusual, you're not going to be needing POLLOUT ever. Hence I don't want to add any cost for it, I'd even advocate just doing waitqueue_active() perhaps, if we can safely pull it off. -- Jens Axboe