Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp591272pxb; Wed, 27 Jan 2021 16:04:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJymiuRdhtEhXEy56twE0Xy0RgMPea3Ks0CJv0U3tJ/zA2zXO6JCjTgNGBrY59uVuCmBhxir X-Received: by 2002:a17:906:c1c1:: with SMTP id bw1mr8924046ejb.86.1611792289237; Wed, 27 Jan 2021 16:04:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611792289; cv=none; d=google.com; s=arc-20160816; b=eyCI8wdWjobne9y240e/Hj1qZGzbXJZa+UIoxNvYC5F99kn0VCwBbf4hNj6RPJS5Gy P40/z/e8De2bMXN21eEPKeAg0H8vPgy2xoscriHr65oQHGuHBOWtO9/vAAjrhBHcjaQI bEvcxjt8yb9g0OWfk7q+PQoFfwYVEMr+XdblUB9IPg5Jf+ElHLwu9LvVlc1M9dLDRabL OQmfW1VhW1891sCAlBWsrGkcPSAmxsF36qyv1gHgJfOZidFcyENvDJbQNY/MbmIE5jBE RDXZaYJPN7Gh1Xe7RvX0RM4uMBetkEmgjEfGVPbO9dWE+AdnpL0x+djBBJRuOCVpTmkx 5Hwg== 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=Y8CI0qhLiRTzgvTJnz39fBqQX6rleE9goWMGoeQDUHM=; b=rsvbXk2dM5Dw+SvfjlfNhuo9dNsQdBwolS9qYqcZ4UZYv5R85Wn21rTEfwolNEXCjj F2rXcTmf7EcEh88S27Ps8kpeTucNKdZHAwwC52a9xVuJ8SE+teKlc/osVFRJyO7eaboU k7V+vebKYZ7ADXBr6fTHVzejjneZRWVCypH0ERQb0rufCta4zhsiCJddKdm7uHE0hyuD SQcHjeG3+RMaU7T+h/RK99VlARnYDuH/2pJcQHqQ7xKKsQxCgik/vjfJtQgMsPvs3Sw2 SSnybci2W9PPTvtE1HT4/+gRunrhfAwnzlM010uvpzgj0Ge1jqbOMbCPMwoF3NExhwTi 9AMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=a7tsz9TT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e6si1952925edz.362.2021.01.27.16.04.23; Wed, 27 Jan 2021 16:04:49 -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=@redhat.com header.s=mimecast20190719 header.b=a7tsz9TT; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235886AbhA0PZC (ORCPT + 99 others); Wed, 27 Jan 2021 10:25:02 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:49290 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343837AbhA0PUU (ORCPT ); Wed, 27 Jan 2021 10:20:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611760734; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Y8CI0qhLiRTzgvTJnz39fBqQX6rleE9goWMGoeQDUHM=; b=a7tsz9TTubscatFWvEvc/rQiaezS3f5SMmxhQy3n+UqH33/4+bMWEtuM3HP91uM7P9g1fm M6ncizZwR+eSjeRMP3SQVL3AnXid7US1+zafq/LuB5RnQBiy5oSGZyrqZZ3Qyw07iK2V88 K2Cj1tAdYjWoZZIeFgXlQQcfq3o04ss= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-Q_p0DMDDOLWzMbA0s1tO-Q-1; Wed, 27 Jan 2021 10:18:50 -0500 X-MC-Unique: Q_p0DMDDOLWzMbA0s1tO-Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 826648797E7; Wed, 27 Jan 2021 15:18:48 +0000 (UTC) Received: from T590 (ovpn-12-152.pek2.redhat.com [10.72.12.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 634A45D9CA; Wed, 27 Jan 2021 15:18:44 +0000 (UTC) Date: Wed, 27 Jan 2021 23:18:38 +0800 From: Ming Lei To: Maxim Mikityanskiy Cc: Bart Van Assche , Jens Axboe , Alexander Viro , Christoph Hellwig , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] Revert "block: simplify set_init_blocksize" to regain lost performance Message-ID: <20210127151838.GA1325688@T590> References: <20210126195907.2273494-1-maxtram95@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2021 at 09:44:50AM +0200, Maxim Mikityanskiy wrote: > On Wed, Jan 27, 2021 at 6:23 AM Bart Van Assche wrote: > > > > On 1/26/21 11:59 AM, Maxim Mikityanskiy wrote: > > > The cited commit introduced a serious regression with SATA write speed, > > > as found by bisecting. This patch reverts this commit, which restores > > > write speed back to the values observed before this commit. > > > > > > The performance tests were done on a Helios4 NAS (2nd batch) with 4 HDDs > > > (WD8003FFBX) using dd (bs=1M count=2000). "Direct" is a test with a > > > single HDD, the rest are different RAID levels built over the first > > > partitions of 4 HDDs. Test results are in MB/s, R is read, W is write. > > > > > > | Direct | RAID0 | RAID10 f2 | RAID10 n2 | RAID6 > > > ----------------+--------+-------+-----------+-----------+-------- > > > 9011495c9466 | R:256 | R:313 | R:276 | R:313 | R:323 > > > (before faulty) | W:254 | W:253 | W:195 | W:204 | W:117 > > > ----------------+--------+-------+-----------+-----------+-------- > > > 5ff9f19231a0 | R:257 | R:398 | R:312 | R:344 | R:391 > > > (faulty commit) | W:154 | W:122 | W:67.7 | W:66.6 | W:67.2 > > > ----------------+--------+-------+-----------+-----------+-------- > > > 5.10.10 | R:256 | R:401 | R:312 | R:356 | R:375 > > > unpatched | W:149 | W:123 | W:64 | W:64.1 | W:61.5 > > > ----------------+--------+-------+-----------+-----------+-------- > > > 5.10.10 | R:255 | R:396 | R:312 | R:340 | R:393 > > > patched | W:247 | W:274 | W:220 | W:225 | W:121 > > > > > > Applying this patch doesn't hurt read performance, while improves the > > > write speed by 1.5x - 3.5x (more impact on RAID tests). The write speed > > > is restored back to the state before the faulty commit, and even a bit > > > higher in RAID tests (which aren't HDD-bound on this device) - that is > > > likely related to other optimizations done between the faulty commit and > > > 5.10.10 which also improved the read speed. > > > > > > Signed-off-by: Maxim Mikityanskiy > > > Fixes: 5ff9f19231a0 ("block: simplify set_init_blocksize") > > > Cc: Christoph Hellwig > > > Cc: Jens Axboe > > > --- > > > fs/block_dev.c | 10 +++++++++- > > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > > > diff --git a/fs/block_dev.c b/fs/block_dev.c > > > index 3b8963e228a1..235b5042672e 100644 > > > --- a/fs/block_dev.c > > > +++ b/fs/block_dev.c > > > @@ -130,7 +130,15 @@ EXPORT_SYMBOL(truncate_bdev_range); > > > > > > static void set_init_blocksize(struct block_device *bdev) > > > { > > > - bdev->bd_inode->i_blkbits = blksize_bits(bdev_logical_block_size(bdev)); > > > + unsigned int bsize = bdev_logical_block_size(bdev); > > > + loff_t size = i_size_read(bdev->bd_inode); > > > + > > > + while (bsize < PAGE_SIZE) { > > > + if (size & bsize) > > > + break; > > > + bsize <<= 1; > > > + } > > > + bdev->bd_inode->i_blkbits = blksize_bits(bsize); > > > } > > > > > > int set_blocksize(struct block_device *bdev, int size) > > > > How can this patch affect write speed? I haven't found any calls of > > set_init_blocksize() in the I/O path. Did I perhaps overlook something? > > I don't know the exact mechanism how this change affects the speed, > I'm not an expert in the block device subsystem (I'm a networking > guy). This commit was found by git bisect, and my performance test > confirmed that reverting it fixes the bug. > > It looks to me as this function sets the block size as part of control > flow, and this size is used later in the fast path, and the commit > that removed the loop decreased this block size. Right, the issue is stupid __block_write_full_page() which submits single bio for each buffer head. And I have tried to improve the situation by merging BHs into single bio, see below patch: https://lore.kernel.org/linux-block/20201230000815.3448707-1-ming.lei@redhat.com/ The above patch should improve perf for your test case. -- Ming