Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4168516pxb; Tue, 26 Jan 2021 14:21:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJyr+75y9f6XBDNOPISNChzxMT+C8HwYro/ldya4lmzUerjOcVzG/33+rMJ8cjvHZBKqLzx/ X-Received: by 2002:aa7:c384:: with SMTP id k4mr6073412edq.23.1611699687534; Tue, 26 Jan 2021 14:21:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611699687; cv=none; d=google.com; s=arc-20160816; b=cwdCa2LpNwfSDK2BYk6qx073jsOeHWCO5NoSFf3DMSPsO7J7wltq4K72yINUil6TPv K/nCozldPxu/Jltx3CEPlchYmNegWC2uRop1Bg5v+KIK74Y+UPVFFpoRxIf8uqN2idtb HoGbCecHArHtBFr3wldpw7r3dCE/Yesdj+5lgOQvULzOJwpWWeqiESLuNkRVypGDygk1 n5wdDGwnAWC/cHXrlPfucYQHeUgO2/Y6hxe3I7S5qPm04ZzFNL+OobSfv4aS8LfVhdBn R9z96HGwa2iewI63PmCA+SRh7jNKSVQbojWPr9OOJIlNcPTf/kwbVUlh5zj68JeXt7Ms kmfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=mjV/4Z3CDRxQhs+wKq1+GM3JPWdjP4pMPtKxh3gu3Qg=; b=WPBP7x7Z/MmBIxkyBCBcNSVgL8SSQ94wfrngNvDgrB/5S2R7ov39AB08Pw+to9iUmq P4TFLFonKvbYoX41UCtt4k4RoDeI8wXDCUb27CxT3oywJCvCsmhYGjcH4y2cyouUe2vr Zj1tzDWumY7ncS6OhUTU3d3s5LwtcjOnpDIonahWZYDNYSE9J9+eBmr75uBAIH/AUb/E Oamk9vdpNh1A8Ws+1JxCxsY0ix6+eHUCbwXJphVJ/wyBeorRPmr68QK2m0chft2mlOhe +iFrB0oj1gsPX1trfS+scFG/7U/YvTyt2+x+BTg2/aQBXjsAE4xEwMtFZD+Lmx7NRwT6 f+XQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=qnNhg72w; 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 e18si1140275edz.446.2021.01.26.14.20.34; Tue, 26 Jan 2021 14:21:27 -0800 (PST) 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; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=qnNhg72w; 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 S1728420AbhAZFZC (ORCPT + 99 others); Tue, 26 Jan 2021 00:25:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727242AbhAYKAN (ORCPT ); Mon, 25 Jan 2021 05:00:13 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B409C0617AA; Mon, 25 Jan 2021 00:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=mjV/4Z3CDRxQhs+wKq1+GM3JPWdjP4pMPtKxh3gu3Qg=; b=qnNhg72wYDhaBpZbjBxRedU+0p y18yUOE0T3saR/wjRv9Aysq05dijQ7rGD5IeOiFPH4IulcBXMa3mSOHz0nsjGONuGjnX8bUxe91Lq o0iftOB1HJRWIZKgbAeUX4mB9TIgk7jLu/uAP9L1t8upK9ueQWwbbOlUgvqt/ZQjEXoM0KwZG+rou 3qUKywQdTwqdQxaEgTi6nJlEmmzNg13jdVCmIRVlCP50Kroa0OZiFB+esbyPn8aL4CaRTfVBIbVQi 0tdq9by/K4+pPYMA2KFWLNuUh2lqwMMtMUm2P7OYZsltG6zVCZ+V+b+veepwSUlfVj8Fek4VCXNzW ccCPJNOA==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1l3xIm-003y01-HS; Mon, 25 Jan 2021 08:32:49 +0000 Date: Mon, 25 Jan 2021 08:32:48 +0000 From: Christoph Hellwig To: Sebastian Andrzej Siewior Cc: Christoph Hellwig , Hannes Reinecke , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , Thomas Gleixner , Peter Zijlstra , Ingo Molnar Subject: Re: [PATCH 2/3] blk-mq: Always complete remote completions requests in softirq Message-ID: <20210125083248.GA945284@infradead.org> References: <20210123201027.3262800-1-bigeasy@linutronix.de> <20210123201027.3262800-3-bigeasy@linutronix.de> <30ce5ce2-8b9a-8873-4b37-c8720300942b@suse.de> <20210125082542.GC942655@infradead.org> <20210125083029.utnjqs2s3diqb5vx@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210125083029.utnjqs2s3diqb5vx@linutronix.de> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 25, 2021 at 09:30:29AM +0100, Sebastian Andrzej Siewior wrote: > On 2021-01-25 08:25:42 [+0000], Christoph Hellwig wrote: > > On Mon, Jan 25, 2021 at 08:10:16AM +0100, Hannes Reinecke wrote: > > > I don't get this. > > > This code is about _avoiding_ having to raise a softirq if the driver > > > exports more than one hardware queue. > > > So where exactly does the remote CPU case come in here? > > > > __blk_mq_complete_request_remote is only called for the case where we > > do not completelky locally. The case that "degrades" here is where > > the device supports multiple queues, but less than the number of CPUs, > > and we bounce the completion to another CPU. > > Does it really "degrade" or just use the softirq more often? The usual > case is run the softirqs in irq_exit() which is just after IPI. Well, I put it in quotes because I'm not sure what the exact effect is. But we do delay these completions to the softirq now instead of hardirq context, which at least in theory increases latency. OTOH it might even have positive effects on the rest of the system.