Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757611Ab0GGUGM (ORCPT ); Wed, 7 Jul 2010 16:06:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48897 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809Ab0GGUGK convert rfc822-to-8bit (ORCPT ); Wed, 7 Jul 2010 16:06:10 -0400 From: Jeff Moyer To: Corrado Zoccolo Cc: Jens Axboe , Linux-Kernel , Vivek Goyal Subject: Re: [PATCH 0/2] cfq-iosched: fixing RQ_NOIDLE handling. References: 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: Wed, 07 Jul 2010 16:06:04 -0400 In-Reply-To: (Corrado Zoccolo's message of "Wed, 7 Jul 2010 19:39:49 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2471 Lines: 58 Corrado Zoccolo writes: > On Wed, Jul 7, 2010 at 7:03 PM, Jeff Moyer wrote: >> Corrado Zoccolo writes: >> >>> Hi Jens, >>> patch 8e55063 "cfq-iosched: fix corner cases in idling logic", is >>> suspected for some regressions on high end hardware. >>> The two patches from this series: >>> - [PATCH 1/2] cfq-iosched: fix tree-wide handling of rq_noidle >>> - [PATCH 2/2] cfq-iosched: RQ_NOIDLE enabled for SYNC_WORKLOAD >>> fix two issues that I have identified, related to how RQ_NOIDLE is >>> used by the upper layers. >>> First patch makes sure that a RQ_NOIDLE coming after a sequence of >>> possibly idling requests from the same queue on the no-idle tree will >>> clear the noidle_tree_requires_idle flag. >>> Second patch enables RQ_NOIDLE for queues in the idling tree, >>> restoring the behaviour pre-8e55063 patch. >> >> Hi, Corrado, >> >> I ran your kernel through my tests.  Here are the results, up against >> vanilla, deadline, and the blk_yield patch set: >> > Hi Jeff, > can you also add cfq with 8e55063 reverted to the testing mix? Sure, the results now look like this: just just fs_mark fio mixed -------------------------------+-------------- deadline 529.44 151.4 | 450.0 78.2 vanilla cfq 107.88 164.4 | 6.6 137.2 blk_yield cfq 530.82 158.7 | 113.2 78.6 corrado cfq 110.16 220.6 | 7.0 159.8 8e55063 revert 559.66 198.9 | 16.1 153.3 I had accidentally run your patch set (corrado cfq) on ext3, so the numbers were a bit off (everything else was run against ext4). The corrected numbers above reflect the performance on ext4, which is much better for the sequential reader, but still not great for the fs_mark run. Reverting 8e55063 definitely gets us into better shape. However, if we care about the mixed workload, then it won't be enough. It's worth noting that I can't explain that jump from 151MB/s for deadline vs 220MB/s for corrado cfq. I'm not sure how you can vary driving a single queue depth sequential read at all. Those are the averages of 5 runs and this storage should be solely accessible by me, so I am at a loss. Cheers, 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/