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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A4B3C77B73 for ; Thu, 27 Apr 2023 17:45:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244273AbjD0Rpf (ORCPT ); Thu, 27 Apr 2023 13:45:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244178AbjD0Rpe (ORCPT ); Thu, 27 Apr 2023 13:45:34 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDA1249C4 for ; Thu, 27 Apr 2023 10:45:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 737F35C00D3; Thu, 27 Apr 2023 13:45:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 27 Apr 2023 13:45:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devkernel.io; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1682617507; x=1682703907; bh=TG lI3W+NADHtX80jzQq4o9Nj8WP+sezCa7SDCHDM2KY=; b=XK+IhEk8oXHdzx9/6L 8wQB+wzgjpYMEIfvKl9zwwQhzd0TNjDtCjB9M17yoSBgwzRbGK70cF50ik2g/51m konChDZjpFbMOszDF1jFcN5RAowr86sAojVTiTJ+CHHEp2xGzXyFTxkPkUwf048s H1CfwF97tB47rymIGhVXPJvjMwIbXVqYJqccoS7m/a98TSUNu5DaDbNWvsiDZX+K MsiecOz3ftylsZC1cwGuhHCKSN6jeVcm18noLRhrc5wD1XSCYJ4cJAYIh/XvkMH5 G3ntTCByYaZHuPglb0QSPRdUXoDP6Xdmzue794yYMTKI0adBBvv1CAlvu9E7hJak RRQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1682617507; x=1682703907; bh=TGlI3W+NADHtX 80jzQq4o9Nj8WP+sezCa7SDCHDM2KY=; b=Wq92JLAJEsqqA6T0+zM0Lx/IZyaev uHJ6CqS4DYRn9mYj5oukw0DwPm0G1RZOHW1uhYAJKc+nDppV3jN+syo/ZMtr/cPJ GiLPhFhnpWpDeWW2AqK+2uH1bZ4MEFIWNAmpVq3nL7pDg/8SB63Ud75sbqNzaLnL qS3UJuyXWQm+HBTVvBdAtZlamskBaRH2xr8yTiLu3vgVdFagrofCOR/2yCnDm37N P+1SOEVTdX17m2kr6C3hpVyWtpUtz1Bw6n3yiV3CvpxggoljKbUj8Ta6WnTYHmW4 RCXNKsODMBUoovcjGwHjwPKfKS5MJbdnHDlA/gEA//dmJPJmxzhD/9Iqg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeduiedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefuthgv fhgrnhcutfhovghstghhuceoshhhrhesuggvvhhkvghrnhgvlhdrihhoqeenucggtffrrg htthgvrhhnpeevlefggffhheduiedtheejveehtdfhtedvhfeludetvdegieekgeeggfdu geeutdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hshhhrseguvghvkhgvrhhnvghlrdhioh X-ME-Proxy: Feedback-ID: i84614614:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Apr 2023 13:45:06 -0400 (EDT) References: <20230425181845.2813854-1-shr@devkernel.io> <20230425181845.2813854-3-shr@devkernel.io> User-agent: mu4e 1.10.1; emacs 28.2.50 From: Stefan Roesch To: Jens Axboe Cc: io-uring@vger.kernel.org, kernel-team@fb.com, ammarfaizi2@gnuweeb.org, Olivier Langlois , Jakub Kicinski Subject: Re: [PATCH v10 2/5] io-uring: add napi busy poll support Date: Thu, 27 Apr 2023 10:44:49 -0700 In-reply-to: Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org Jens Axboe writes: > On 4/26/23 7:41?PM, Jens Axboe wrote: >>> +static void io_napi_multi_busy_loop(struct list_head *napi_list, >>> + struct io_wait_queue *iowq) >>> +{ >>> + unsigned long start_time = busy_loop_current_time(); >>> + >>> + do { >>> + if (list_is_singular(napi_list)) >>> + break; >>> + if (!__io_napi_busy_loop(napi_list, iowq->napi_prefer_busy_poll)) >>> + break; >>> + } while (!io_napi_busy_loop_should_end(iowq, start_time)); >>> +} >> >> Do we need to check for an empty list here? >> >>> +static void io_napi_blocking_busy_loop(struct list_head *napi_list, >>> + struct io_wait_queue *iowq) >>> +{ >>> + if (!list_is_singular(napi_list)) >>> + io_napi_multi_busy_loop(napi_list, iowq); >>> + >>> + if (list_is_singular(napi_list)) { >>> + struct io_napi_ht_entry *ne; >>> + >>> + ne = list_first_entry(napi_list, struct io_napi_ht_entry, list); >>> + napi_busy_loop(ne->napi_id, io_napi_busy_loop_should_end, iowq, >>> + iowq->napi_prefer_busy_poll, BUSY_POLL_BUDGET); >>> + } >>> +} >> >> Presumably io_napi_multi_busy_loop() can change the state of the list, >> which is why we have if (cond) and then if (!cond) here? Would probably >> warrant a comment as it looks a bit confusing. > > Doesn't look like that's the case? We just call into > io_napi_multi_busy_loop() -> napi_busy_loop() which doesn't touch it. So > the state should be the same? > > We also check if the list isn't singular before we call it, and then > io_napi_multi_busy_loop() breaks out of the loop if it is. And we know > it's not singular when calling, and I don't see what changes it. > > Unless I'm missing something, which is quite possible, this looks overly > convoluted and has extra pointless checks? I'll fix it.