Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3860442pxb; Fri, 4 Feb 2022 19:29:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxsRVjmlglmO9wcHwXMFbeqEHI4tK7r0MwVG1Jf3KFxl1Y9inCWjtPaLVg3p/kutstdFhzp X-Received: by 2002:aa7:d8c5:: with SMTP id k5mr2327589eds.420.1644031783125; Fri, 04 Feb 2022 19:29:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644031783; cv=none; d=google.com; s=arc-20160816; b=CVj59QYWPy57Qhrs4WgMZ16HhGC4srbnfSR2znTPqdFZ4f59IxhjfGrGdMeelxwu2F DqtJgQwHVEMfEgDtdGlbJ6NPu2gdqBItXBin5lnpW7JQygMs3sK/jnkHMVH6i5d0TZFS N/RUMHMXYYtORpxR+rSSUGVFeE45RSyUiR3P+kW8GBbyGd1q/SONa6PGH4E21JCszms1 8a6wqvLnJ/MYpL4kWjB1gA/al9dgzoDpAE2Y7MZh6fvQ8WyimKukYUvdPL2MBTnPXOyb 1iOKWER0isUQ1qZl/2LOpPBfFAIdEkK8UkEhfwv4zNQ9YREvSE1E9Irab/0jvZ+ezUIg o8Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=efrA0nfqvc7zMWFpa4GfAQVSk6pSwKEuqGuv155lv+c=; b=ZxnOuKHTrjuYvDQNyPV8+8nyonMZwJowCMYXkPiZyFAC+xHrMb8j233qZ6cGk0oNJD tMvWKWaHimHaeDn9+72fgcs98KO3yPwBkOQhtVwmZcJaucrvl/3N02FG8duurlBDi3Ah WFGNekQEuzJ4jis+0TpIvTtJLNCe5CeEXTBFy6IAUw31bgsSesqliS/ud2BHSwopdhqp g/La9fyLhjOUno2qHKvWmg+pk2JhaL6DIYnzLdViWamzJHGTd+Kqy+12NYEESFIop5dF PAiex8RBtfHbOMIuaNagnDVNX7VVZnLatuxuBqhzYmTXSH1eW4zq22X+wolu0y8+2+MM Y+sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=2UU6nQWb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l6si2740764ejo.623.2022.02.04.19.29.18; Fri, 04 Feb 2022 19:29:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=2UU6nQWb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355910AbiBDAQB (ORCPT + 99 others); Thu, 3 Feb 2022 19:16:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239553AbiBDAQA (ORCPT ); Thu, 3 Feb 2022 19:16:00 -0500 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 376C1C061714 for ; Thu, 3 Feb 2022 16:16:00 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id 77so822494pgc.0 for ; Thu, 03 Feb 2022 16:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=efrA0nfqvc7zMWFpa4GfAQVSk6pSwKEuqGuv155lv+c=; b=2UU6nQWbWC914x6PRqAMumJXJg4W3WmyOnfnZSyol+FxNCbDYQzadR09gqiqt6GG2H CD4RIO5d/AuIiiH9NzLcvz6R+7udRd7g2D/Aym1TvvbLj/NdGyCZJqLkbvJAMr2LWb+5 y6O7cwvwt4m+dpjcj9CuGoz2JssjDeaqsvNxLv7TxnsRfRojbeqfTUhuDDm5hHQ1VsUu owlauUw0v7OhCE6NpQNzotpt9irqvO1TpLS8L2qQ6hfFwSFH1Uwz0Eg4Izc42UU/OAK5 hV+XBvfNEI5RLILq4HSIi7/o9sQGx8zVfiGVKPxMnyFK0RUaI/axuR1vElqGyN7vMvCY Xghg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=efrA0nfqvc7zMWFpa4GfAQVSk6pSwKEuqGuv155lv+c=; b=4OCJv8RNt98nPW7Kaee7iEN4EK5YQaYW7mPXBPSIUa7TkMeXMl7OxQ8QAzkJDXYboU sft0k0KgqtV88buqd6FTjRTyEnwtXJ04DJWAPjDPblyF2MjtevC4EcEVGWclYV4LjKQA j+eqJCdSJvW4Z2Pjbjqz06bCzlvAV+NJpFjjutLJB0Wj6YLdOs3u6UFa5Uv0TC/NvpGW tmgI3hMZKedMSvemzUAbCKrgt+2Lu79/S8cZKsanmn0aP30fNFIezxEOOwzZ0BxMTefp qIGw34Ay7EJZ+JmHz5sPX94W3pSgmMCupS4qUdJLInzDFKgUI+l+TOpCZ9wX4l2MJJS7 FLRg== X-Gm-Message-State: AOAM530JGCmkNwnSfUb3QuujNNIqLQteRe3nVscbFYXUyc8XwcOqZar5 qjLP4j2rUPptFLvM5Q6NFWMC0g== X-Received: by 2002:a65:538e:: with SMTP id x14mr448133pgq.58.1643933759633; Thu, 03 Feb 2022 16:15:59 -0800 (PST) Received: from [192.168.1.116] ([66.219.217.159]) by smtp.gmail.com with ESMTPSA id ck21sm110090pjb.51.2022.02.03.16.15.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 16:15:59 -0800 (PST) Subject: Re: [PATCH v5 0/4] io_uring: remove ring quiesce in io_uring_register To: Pavel Begunkov , Usama Arif , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Cc: fam.zheng@bytedance.com References: <20220203233439.845408-1-usama.arif@bytedance.com> <16997265-18fa-64db-32e2-4af7f4dc3e4c@gmail.com> From: Jens Axboe Message-ID: Date: Thu, 3 Feb 2022 17:15:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <16997265-18fa-64db-32e2-4af7f4dc3e4c@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/3/22 5:02 PM, Pavel Begunkov wrote: > On 2/3/22 23:34, Usama Arif wrote: >> For opcodes relating to registering/unregistering eventfds, this is done by >> creating a new RCU data structure (io_ev_fd) as part of io_ring_ctx that >> holds the eventfd_ctx, with reads to the structure protected by >> rcu_read_lock and writes (register/unregister calls) protected by a mutex. >> >> With the above approach ring quiesce can be avoided which is much more >> expensive then using RCU lock. On the system tested, io_uring_reigster with >> IORING_REGISTER_EVENTFD takes less than 1ms with RCU lock, compared to 15ms >> before with ring quiesce. >> >> The second patch creates the RCU protected data structure and removes ring >> quiesce for IORING_REGISTER_EVENTFD and IORING_UNREGISTER_EVENTFD. >> >> The third patch builds on top of the second patch and removes ring quiesce >> for IORING_REGISTER_EVENTFD_ASYNC. >> >> The fourth patch completely removes ring quiesce from io_uring_register, >> as IORING_REGISTER_ENABLE_RINGS and IORING_REGISTER_RESTRICTIONS dont need >> them. > > Let me leave it just for history: I strongly dislike it considering > there is no one who uses or going to use it. Are you referring to the 4th patch? Or the patchset as a whole? Not clear to me, because eventfd registration is most certainly used by folks today. > Even more, I can't find a single user of io_uring_unregister_eventfd() > in liburing tests, so most probably the paths are not tested at all. That's definitely a general issue, not related to this patchset. Something that most certainly should get added! Ring exit will use the same unregister path for eventfd, however, so it does get exercised from there with existing tests too. But for this change, we definitely need a test that exercises both register and unregister, trying to trigger something funky there. -- Jens Axboe