Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2515360imm; Mon, 24 Sep 2018 05:46:28 -0700 (PDT) X-Google-Smtp-Source: ACcGV63I25occc34D48iF017MxromgZ74fDvvHDRBi0DyU/jfUVIEcSDFh5NMz9Gkz4vC/DNb8Ee X-Received: by 2002:a17:902:34a:: with SMTP id 68-v6mr10628509pld.39.1537793188922; Mon, 24 Sep 2018 05:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537793188; cv=none; d=google.com; s=arc-20160816; b=tDEIwCFHRgFV57VEGutY+eazwQRKkZf1GG2m6XAKlsFI1ycsLGjMBNdWG9L2RA8mTy fuC3zzl/gNDwtGq13OoxncLSbzm0vydmy/Mb9LWYgtDA3NXX/FkyTVzCi036jRO5x+9X ZyHJuxFzJFF0EWwrq1Vujn1GKPTvy+ODknsI2eoZdyMuQmAljzFMq1qis+FAPvp4fOXA GEzvekrh+go8Y5ak2BVzc+VW/ONJ7rpQBR/4GREcUwLntmJ8O3Mj1pKzuvYtZSzJz5sY xBAu2hUOZQracjp4XW/KvXz+WWcIY992VYcXvSh2hIdbvT/l82t4oEYdblZjtdRHLoXN Tb/Q== 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:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from; bh=lkb76vjtq6IZDE0YgloclGRUBHEcyB9iyRLt0SzPoZk=; b=vYTd9lnvSNHhnq65LZP2A6EsS12f1S5Wl1WzneHiYE+tSBAhRJgTB7NArPJ/xrje8o 4myKTDIZugqme885POEfq53iXSWbXWlXrS2dCSA/0/iL7mzHe1j5QFVwR8IUKVzGK789 dEYD/H8uIzblDRsRJdYlBEl9d4B63SZKFDisEVz5yXCmIOLSSiCVT+aVseyH2Vh1H5Lx bbndDdr/71R80GNhCyqoPZ2HiNn+Fkty3uSWslhTBruXcznYZEF74Yum5QvePEHag5+K G420abxoLML9oL+2IvcYjymN340Xs08R6QkzWpW8BLCCTNDJlupeT1lwgBQLJAG1IKDo vZ8A== ARC-Authentication-Results: i=1; mx.google.com; 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 r7-v6si31681037ple.309.2018.09.24.05.46.12; Mon, 24 Sep 2018 05:46:28 -0700 (PDT) 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; 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 S2389306AbeIXSrL (ORCPT + 99 others); Mon, 24 Sep 2018 14:47:11 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59732 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730322AbeIXSrK (ORCPT ); Mon, 24 Sep 2018 14:47:10 -0400 Received: from localhost (ip-213-127-77-73.ip.prioritytelecom.net [213.127.77.73]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id B4605109F; Mon, 24 Sep 2018 12:45:10 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Laurence Oberman , Omar Sandoval , Bart Van Assche , Kashyap Desai , Christoph Hellwig , Ming Lei , Jens Axboe , Sasha Levin Subject: [PATCH 4.18 228/235] blk-mq: only attempt to merge bio if there is rq in sw queue Date: Mon, 24 Sep 2018 13:53:34 +0200 Message-Id: <20180924113125.776960794@linuxfoundation.org> X-Mailer: git-send-email 2.19.0 In-Reply-To: <20180924113103.999624566@linuxfoundation.org> References: <20180924113103.999624566@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ming Lei [ Upstream commit b04f50ab8a74129b3041a2836c33c916be3c6667 ] Only attempt to merge bio iff the ctx->rq_list isn't empty, because: 1) for high-performance SSD, most of times dispatch may succeed, then there may be nothing left in ctx->rq_list, so don't try to merge over sw queue if it is empty, then we can save one acquiring of ctx->lock 2) we can't expect good merge performance on per-cpu sw queue, and missing one merge on sw queue won't be a big deal since tasks can be scheduled from one CPU to another. Cc: Laurence Oberman Cc: Omar Sandoval Cc: Bart Van Assche Tested-by: Kashyap Desai Reported-by: Kashyap Desai Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- block/blk-mq-sched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/blk-mq-sched.c +++ b/block/blk-mq-sched.c @@ -339,7 +339,8 @@ bool __blk_mq_sched_bio_merge(struct req return e->type->ops.mq.bio_merge(hctx, bio); } - if (hctx->flags & BLK_MQ_F_SHOULD_MERGE) { + if ((hctx->flags & BLK_MQ_F_SHOULD_MERGE) && + !list_empty_careful(&ctx->rq_list)) { /* default per sw-queue merge */ spin_lock(&ctx->lock); ret = blk_mq_attempt_merge(q, ctx, bio);