Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp603671ybf; Sat, 29 Feb 2020 11:01:22 -0800 (PST) X-Google-Smtp-Source: APXvYqztJ6sxjTm3zgvDsECDjQHgaWya9WlROln1aMXnNifre4Q3SMx1crYaMqRUQDr/zlQ+pTMu X-Received: by 2002:aca:33d5:: with SMTP id z204mr6581356oiz.120.1583002882550; Sat, 29 Feb 2020 11:01:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583002882; cv=none; d=google.com; s=arc-20160816; b=xDFXWjuPATVA8mXmhcgfQ76smx2MUWe471oNMvJzM3dvi7O3S3GeGz8jdedetC27Xy E2jole7IXWmYIb/Is8kIlT8YF7PLMGvgeboU5mdoOq1Y/FgfCxWgUDHh2x9TNIf7uVs0 KRV7vtQrj9bj31/djmIIAjEy1JiNYj/TNx7IqJWeUubTQP0LjZOJUmQTkyVu+ds/ZP/4 73sz0OCjp5BkJr7aARQD5oFkmefztrutxj4c2ey80NjmR0ib/EEVP589bbIgEIWsmt6t ZmkBdGkiCF/7ctdqCI9UmgzUpJ5piQyX+onWcO0c6SIlYnEkgXrBy6DfDfpsI6KfhbW0 jKdw== 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:to:subject:dkim-signature; bh=sac+PmgYd9Ne11i2xBwpQkfiU9kowkipYWbptuvvnFw=; b=h09XcPR28Cccr12YhTbBt11b14QnvI93ETKb6/NQNHXK2h5WDKrHWvQDofuFZQN1hF 0dLQW/WvO3hOAc7T6FPLtcY9A40LsmYEeS/DVCtfIac04NnQMgr902qG4UBtui8AxY3h qA44Iftk9HedP/mI6kF7U1wudZkkGTrWNtt6hvMwrY0kBDcIDBUy9ztyRLf1SHeR3P/S u3yPxE+q4nCrmA43WWD6kkxenerehUE9IsiZKylRZ+XPldX0qygZiQQYyKIcwhTO4WUK 1iMNWb3mk2kqpXcOUlDctzi61w2gjp1WCVBTFmLA2pEOW1KftA6GMQcq+qBemy1Tk3y3 2+rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b="R4z/DKbt"; 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 i19si176390oie.131.2020.02.29.11.01.11; Sat, 29 Feb 2020 11:01:22 -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="R4z/DKbt"; 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 S1727552AbgB2TAR (ORCPT + 99 others); Sat, 29 Feb 2020 14:00:17 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:43866 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727258AbgB2TAQ (ORCPT ); Sat, 29 Feb 2020 14:00:16 -0500 Received: by mail-pg1-f194.google.com with SMTP id u12so3259116pgb.10 for ; Sat, 29 Feb 2020 11:00:15 -0800 (PST) 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=sac+PmgYd9Ne11i2xBwpQkfiU9kowkipYWbptuvvnFw=; b=R4z/DKbtXdeAv/OuQ9d9v1ISo1ATLBmrv2aWuysEW6ooe9h/rTPgAsDKZ2YC/SI2qN MQzEDeoyWr9YLkRgu2iMAlzPXKvIs4/CjfAq61jcEa/CievVDrR/url1Bb+Rin1TSzU1 u+Cm0F73kwxd1TyaVA4Xb8DLPHSJoEUJ18h83f8DqYsirz+SnSvlvpfLUOyFldACkYbF 6F87gV4d9DhZ4D/mvb35oAPn6GgBhAti0rvCO0XtrVwKd8pazmiJ89kDrFIcRQ4e0ON5 hU1kGTLpQ8c1YF9C4N2odM2ewfayyryKsJexxp5nENCpyvJAt01Ye47aO4ZH8oLHjW4+ TgIQ== 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=sac+PmgYd9Ne11i2xBwpQkfiU9kowkipYWbptuvvnFw=; b=WoPLdjoVuCpXAitXPEEUjTjek9Q7xBycLZB6r6FrNEIV1uO8Rz0abNyWZF9A82pNpR kpPhQCnrGt4T+3TyA3Bc0KDNFVkxNM5w+C4BaggHAcsOeriJ8McCb2MDd9UE5jlHWD60 4vKQM04Rp5J2J5532hRVE2rNs07aT7AuBWz9ngrfPxwOM5Xm0F1GFCbnHIs0QaLxFE9I sJyDIy5zuSkpVi8A3LqsiimovDfg8Egzu+mZI85bTGf9gDTsHCaOpn4vyGFip1Q3ah0z 3hCcmkwKAvBIvhKFuEHYTJcPeRxoqONx6A+rQRVW6wS7rJbe3e77jA7zT0R6zgPKnWLq Zv4Q== X-Gm-Message-State: APjAAAVRNVagrkT7GOvkaCwb61MYSak++he8qESG7CBmjio3G4G7irCI b2cC4t9E5UOIZI52zTjWiX76XAe0wkQ= X-Received: by 2002:a63:214e:: with SMTP id s14mr10713408pgm.428.1583002814148; Sat, 29 Feb 2020 11:00:14 -0800 (PST) Received: from [192.168.1.188] ([66.219.217.145]) by smtp.gmail.com with ESMTPSA id q12sm15368255pfh.158.2020.02.29.11.00.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Feb 2020 11:00:13 -0800 (PST) Subject: Re: [PATCH REBASE v2 0/5] return nxt propagation within io-wq ctx To: Pavel Begunkov , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: From: Jens Axboe Message-ID: <5b366775-6d00-3353-995f-d284d78e9a4e@kernel.dk> Date: Sat, 29 Feb 2020 12:00:12 -0700 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/29/20 11:44 AM, Pavel Begunkov wrote: > On 29/02/2020 02:37, Pavel Begunkov wrote: >> After io_put_req_find_next() was patched, handlers no more return >> next work, but enqueue them through io_queue_async_work() (mostly >> by io_put_work() -> io_put_req()). The patchset fixes that. >> >> Patches 1-2 clean up and removes all futile attempts to get nxt from >> the opcode handlers. The 3rd one moves all this propagation idea into >> work->put_work(). And the rest ones are small clean up on top. > > And now I'm hesitant about the approach. It works fine, but I want to > remove a lot of excessive locking from io-wq, and it'll be in the way. > Ignore this, I'll try something else > > The question is whether there was a problem with io_req_find_next() in > the first place... It was stealing @nxt, when it already completed a > request and were synchronous to the submission ref holder, thus it > should have been fine. There was only a problem with it if we have multiple calls of io_put_req_find_next(), so it was a bit fragile. That was the only issue, but that's big enough imho. I'll ignore this series for now, you can always rebase on top of the other stuff if you want to. -- Jens Axboe