From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753556AbbHOBSf (ORCPT ); Fri, 14 Aug 2015 21:18:35 -0400 Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:50275 "HELO gproxy4-pub.mail.unifiedlayer.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751524AbbHOBSe (ORCPT ); Fri, 14 Aug 2015 21:18:34 -0400 X-Authority-Analysis: v=2.1 cv=co0IzTIi c=1 sm=1 tr=0 a=6lV6tj8ir7tGSl/9xQZNPA==:117 a=6lV6tj8ir7tGSl/9xQZNPA==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=N54-gffFAAAA:8 a=7mgLt2wxmooA:10 a=EA5itrwUPoEA:10 a=N659UExz7-8A:10 a=05RPwmwRPNYA:10 a=I4ko-sDDNxYA:10 a=uRRa74qj2VoA:10 a=20KFwNOVAAAA:8 a=TDqPYoJmi1Fyc-prEOgA:9 a=pILNOxqGKmIA:10 Message-ID: <55CE9357.4020109@acm.org> Date: Fri, 14 Aug 2015 21:18:15 -0400 From: Ed Cashin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Jeff Moyer , axboe@kernel.dk, hch@infradead.org CC: linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] Revert "block: remove artifical max_hw_sectors cap" References: <1439492277-14638-1-git-send-email-jmoyer@redhat.com> <1439492277-14638-2-git-send-email-jmoyer@redhat.com> In-Reply-To: <1439492277-14638-2-git-send-email-jmoyer@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {2969:box320.bluehost.com:cashinwo:cashinworks.com} {sentby:smtp auth 98.192.52.118 authed with ed@cashinworks.com} Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ACK. On 08/13/2015 02:57 PM, Jeff Moyer wrote: > This reverts commit 34b48db66e08ca1c1bc07cf305d672ac940268dc. > That commit caused performance regressions for streaming I/O > workloads on a number of different storage devices, from > SATA disks to external RAID arrays. It also managed to > trip up some buggy firmware in at least one drive, causing > data corruption. > > The next patch will bump the default max_sectors_kb value to > 1280, which will accommodate a 10-data-disk stripe write > with chunk size 128k. In the testing I've done using iozone, > fio, and aio-stress, a value of 1280 does not show a big > performance difference from 512. This will hopefully still > help the software RAID setup that Christoph saw the original > performance gains with while still not regressing other > storage configurations. > > Signed-off-by: Jeff Moyer > --- > block/blk-settings.c | 4 +++- > drivers/block/aoe/aoeblk.c | 2 +- > include/linux/blkdev.h | 1 + > 3 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/block/blk-settings.c b/block/blk-settings.c > index 12600bf..b160f89 100644 > --- a/block/blk-settings.c > +++ b/block/blk-settings.c > @@ -257,7 +257,9 @@ void blk_limits_max_hw_sectors(struct queue_limits *limits, unsigned int max_hw_ > __func__, max_hw_sectors); > } > > - limits->max_sectors = limits->max_hw_sectors = max_hw_sectors; > + limits->max_hw_sectors = max_hw_sectors; > + limits->max_sectors = min_t(unsigned int, max_hw_sectors, > + BLK_DEF_MAX_SECTORS); > } > EXPORT_SYMBOL(blk_limits_max_hw_sectors); > > diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c > index 46c282f..dd73e1f 100644 > --- a/drivers/block/aoe/aoeblk.c > +++ b/drivers/block/aoe/aoeblk.c > @@ -395,7 +395,7 @@ aoeblk_gdalloc(void *vp) > WARN_ON(d->flags & DEVFL_TKILL); > WARN_ON(d->gd); > WARN_ON(d->flags & DEVFL_UP); > - blk_queue_max_hw_sectors(q, 1024); > + blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS); > q->backing_dev_info.name = "aoe"; > q->backing_dev_info.ra_pages = READ_AHEAD / PAGE_CACHE_SIZE; > d->bufpool = mp; > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > index d4068c1..1fd459e1 100644 > --- a/include/linux/blkdev.h > +++ b/include/linux/blkdev.h > @@ -1138,6 +1138,7 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t has_write_perm); > enum blk_default_limits { > BLK_MAX_SEGMENTS = 128, > BLK_SAFE_MAX_SECTORS = 255, > + BLK_DEF_MAX_SECTORS = 1024, > BLK_MAX_SEGMENT_SIZE = 65536, > BLK_SEG_BOUNDARY_MASK = 0xFFFFFFFFUL, > };