Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbbDPPrR (ORCPT ); Thu, 16 Apr 2015 11:47:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40570 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753AbbDPPrL (ORCPT ); Thu, 16 Apr 2015 11:47:11 -0400 From: Jeff Moyer To: Jens Axboe Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] blk-plug: don't flush nested plug lists References: <1428347694-17704-1-git-send-email-jmoyer@redhat.com> <1428347694-17704-2-git-send-email-jmoyer@redhat.com> <55256786.8000608@kernel.dk> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Thu, 16 Apr 2015 11:47:10 -0400 In-Reply-To: <55256786.8000608@kernel.dk> (Jens Axboe's message of "Wed, 08 Apr 2015 11:38:14 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2387 Lines: 49 Jens Axboe writes: > And agree with Ming, this can be cleaned up substantially. I'd also > like to see some test results from the other end of the spectrum. Your > posted cased is clearly based case (we missed tons of merging, now we > don't), I'd like to see a normal case and a worst case result as well > so we have an idea of what this would do to latencies. I re-ran my tests (just sequential reads) to verify where the performance benefit comes from. Here are the results: device| vanilla | patch1 | dio-noplug | noflush-nested ------+------------+----------------+---------------+----------------- rssda | 701,684 | 1,168,527 | 1,342,177 | 1,297,612 | 100% | +66% | +91% | +85% vdb0 | 358,264 | 902,913 | 906,850 | 922,327 | 100% | +152% | +153% | +157% Patch1 refers to the first patch in this series, which fixes the merge logic for single-queue blk-mq devices. Each column after that includes that first patch. In dio-noplug, I removed the blk_plug from the direct-io code path (so there is no nesting at all). This is a control, since it is what I expect the outcome of the noflush-nested column to actually be. Then, the noflush-nested column leaves the blk_plug in place in the dio code, but includes the patch that prevents nested blk_plug's from being flushed. All numbers are the average of 5 runs. With the exception of the vanilla run on rssda (the first run was faster, causing the average to go up), the standard deviation is very small. As you can see, for the micron device (rssda) we get quite a bit of an improvement from just fixing the plugging, but we could do quite a bit better. For the virtio-blk device, the follow-on patches don't contribute very much to the overall performance. So, I'm happy to push in just patch 1 at this time. It is a bugfix, after all, and could even be marked for stable. Does that sound reasonable? Later, if time permits, I can look into refining patch 2, though I don't have any firm plans to do that right now. Thanks, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/