Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933423AbcDFBAh (ORCPT ); Tue, 5 Apr 2016 21:00:37 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:27885 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932197AbcDFBAe (ORCPT ); Tue, 5 Apr 2016 21:00:34 -0400 Date: Tue, 5 Apr 2016 17:59:51 -0700 From: Shaohua Li To: Kent Overstreet CC: Jeff Moyer , Ming Lei , Jens Axboe , , , Christoph Hellwig , Eric Wheeler , Sebastian Roesner , "4.2+" Subject: Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs Message-ID: <20160406005951.GA3129698@devbig084.prn1.facebook.com> References: <1459878246-9249-1-git-send-email-ming.lei@canonical.com> <20160405182720.GA2375685@devbig084.prn1.facebook.com> <20160406002733.GB31161@kmo-pixel> <20160406003006.GA3084175@devbig084.prn1.facebook.com> <20160406003604.GE31161@kmo-pixel> <20160406004147.GA3100363@devbig084.prn1.facebook.com> <20160406004555.GA32042@kmo-pixel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160406004555.GA32042@kmo-pixel> User-Agent: Mutt/1.5.20 (2009-12-10) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-06_02:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1231 Lines: 24 On Tue, Apr 05, 2016 at 04:45:55PM -0800, Kent Overstreet wrote: > On Tue, Apr 05, 2016 at 05:41:47PM -0700, Shaohua Li wrote: > > On Tue, Apr 05, 2016 at 04:36:04PM -0800, Kent Overstreet wrote: > > > On Tue, Apr 05, 2016 at 05:30:07PM -0700, Shaohua Li wrote: > > > > this one: > > > > http://marc.info/?l=linux-kernel&m=145926976808760&w=2 > > > > > > Ah. that patch won't actually fix the bug, since md isn't using > > > blk_default_limits, it's using blk_set_stacking_limits(). > > > > Not really, the limit is set by under layer disk not md, otherwise it > > should be BLK_SAFE_MAX_SECTORS, but the reported bio has 2560 sectors. > > blk_set_stacking_limits() will use it. > > What? Well, that could should just be deleted, there's no reason anymore for md > to care about the queue limits of the devices underneath it. > > Regardless, using BLK_DEF_MAX_SECTORS to limit # of pages in the biovec is > _crazy_. Why would you even do that? We have a separate field in queue limits > for # max segments, use it. We don't limit the max segments in blk_queue_max_segments(), but we can add. On the other hand, limit max segments to 256 could be a problem, because bvec page isn't always 4k, this might make some bio smaller.