From patchwork Sun Feb 14 14:02:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sagi Grimberg X-Patchwork-Id: 8302151 Return-Path: X-Original-To: patchwork-linux-block@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 5ECECC02AE for ; Sun, 14 Feb 2016 14:02:52 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 436A720414 for ; Sun, 14 Feb 2016 14:02:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 40C5D203ED for ; Sun, 14 Feb 2016 14:02:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751481AbcBNOCm (ORCPT ); Sun, 14 Feb 2016 09:02:42 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37877 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751452AbcBNOCX (ORCPT ); Sun, 14 Feb 2016 09:02:23 -0500 Received: by mail-wm0-f52.google.com with SMTP id g62so77079609wme.0 for ; Sun, 14 Feb 2016 06:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dev-mellanox-co-il.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=61fqNXlFgvYoQbtw5otJx7tKQouK1Ppnw+Y3WD2jQFU=; b=B/Ik1sLJFgcsCn/HqpTtw2vVdBsr8U14Mb5Ewoa70BQW8LZvnoPFBx3Heczsu9P9Rr mipdtEd8+DPkyx+Q0AGrhZQImomGSNTy0iuXtBLQVrVcGTD3tS+7mVOhAjFZ8j0L7tKo aZsGoTzpXi2O6VJ1sVy+Bjo11R7GWW4OMzTbBQoaMi05QSozsna4yFXWzQ1WryX25NOk 0xsWe+Tp3kFsDn5Xa89q8jU/ajuDR419nyB9DO4nBe/I+Lnuue+j/1FsiU29cWvRt9IX tx3K9A12DvVdwWNOqsTIpSQpOlH/CZYvOMKOqDmgFf6FUcDhvDNt/bmieEUTfuaMNyfd kD8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=61fqNXlFgvYoQbtw5otJx7tKQouK1Ppnw+Y3WD2jQFU=; b=gA2J0w8Q2nJfyGg/e8SdL08SBrp09tFB4csaoAM8Q3CFrbl2rz5TNCEOwWVV6PEN53 GCbnh7wA8SdoS1rTx1Ua0tjXIBpAHmmIcKslKSyNszGNLtD8CnjU9m/4PrHaJV9iNdAR j5+76ReUlbvJrnNFHab31uhxoComVJtQ+SpnGw93k7Id1QD06K4wfvpnTh9rsVcr3oRq EGS/SYtf9+GRB8F+v2H5ct9ImT5Bhul+Lf4155lgR50JXDevGAOPH6DIn6LRvQhJLiQf NPItZX4UD4xpJOpbdCoShi7AycBeFZ2egfgc0UQ7OyRDm6iXiZQj0ebkm4koXcjmYxkU wMaw== X-Gm-Message-State: AG10YOQVV4GSgxdMdd85fNXOuI1VW4tNyU/C+G9uA/1j52V3bpOIr1/aBxXYmmRIyV3l9A== X-Received: by 10.194.23.7 with SMTP id i7mr7750786wjf.9.1455458542180; Sun, 14 Feb 2016 06:02:22 -0800 (PST) Received: from [10.223.3.75] ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id t205sm11131123wmt.23.2016.02.14.06.02.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Feb 2016 06:02:21 -0800 (PST) Subject: Re: 4.5-rc iser issues To: Christoph Hellwig References: <20160214074119.GA24558@infradead.org> <56C04294.3090701@dev.mellanox.co.il> <56C05000.1040001@dev.mellanox.co.il> <56C066AF.6050901@dev.mellanox.co.il> Cc: linux-rdma@vger.kernel.org, Ming Lin-SSI , "linux-nvme@lists.infradead.org" , "linux-block@vger.kernel.org" , Jens Axboe From: Sagi Grimberg Message-ID: <56C088EA.1050901@dev.mellanox.co.il> Date: Sun, 14 Feb 2016 16:02:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C066AF.6050901@dev.mellanox.co.il> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP >> I'm bisecting now, there are a couple of patches from Ming in >> the area of the bio splitting code... >> >> CC'ing Ming, Linux-block and Linux-nvme as iser is identical to nvme >> wrt the virtual boundary so I think nvme will break as well. > > Bisection reveals that this one is the culprit: > > commit 52cc6eead9095e2faf2ec7afc013aa3af1f01ac5 > Author: Ming Lei > Date: Thu Sep 17 09:58:38 2015 -0600 > > block: blk-merge: fast-clone bio when splitting rw bios > > biovecs has become immutable since v3.13, so it isn't necessary > to allocate biovecs for the new cloned bios, then we can save > one extra biovecs allocation/copy, and the allocation is often > not fixed-length and a bit more expensive. > > For example, if the 'max_sectors_kb' of null blk's queue is set > as 16(32 sectors) via sysfs just for making more splits, this patch > can increase throught about ~70% in the sequential read test over > null_blk(direct io, bs: 1M). > > Cc: Christoph Hellwig > Cc: Kent Overstreet > Cc: Ming Lin > Cc: Dongsu Park > Signed-off-by: Ming Lei > > This fixes a performance regression introduced by commit 54efd50bfd, > and allows us to take full advantage of the fact that we have > immutable > bio_vecs. Hand applied, as it rejected violently with commit > 5014c311baa2. > > Signed-off-by: Jens Axboe > -- Looks like there is a problem with bio_clone_fast() This change makes the problem go away: --- -- Any thoughts? -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/block/bio.c b/block/bio.c index dbabd48..5e93733 100644 --- a/block/bio.c +++ b/block/bio.c @@ -1791,7 +1791,7 @@ struct bio *bio_split(struct bio *bio, int sectors, * Discards need a mutable bio_vec to accommodate the payload * required by the DSM TRIM and UNMAP commands. */ - if (bio->bi_rw & REQ_DISCARD) + if (1 || bio->bi_rw & REQ_DISCARD) split = bio_clone_bioset(bio, gfp, bs); else split = bio_clone_fast(bio, gfp, bs);