Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754632AbcC3Rki (ORCPT ); Wed, 30 Mar 2016 13:40:38 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:37233 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753498AbcC3Rkg (ORCPT ); Wed, 30 Mar 2016 13:40:36 -0400 Date: Wed, 30 Mar 2016 10:40:35 -0700 From: Christoph Hellwig To: Shaohua Li Cc: Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@fb.com, Kernel-team@fb.com, "4.2+" , Ming Lei , kent.overstreet@gmail.com Subject: Re: [PATCH] block: don't make BLK_DEF_MAX_SECTORS too big Message-ID: <20160330174035.GA14356@infradead.org> References: <21cf85d32278bbe5acbc3def0a6db75db98a2670.1459269590.git.shli@fb.com> <20160329211833.GA18532@infradead.org> <20160329220053.GA1716708@devbig084.prn1.facebook.com> <20160330065151.GA29666@infradead.org> <20160330165019.GC3552828@devbig084.prn1.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160330165019.GC3552828@devbig084.prn1.facebook.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1535 Lines: 35 On Wed, Mar 30, 2016 at 09:50:30AM -0700, Shaohua Li wrote: > > bcache should be fixed to not allocate larger than allowed bios then. > > And handling too large arguments to bio_alloc_bioset is still useful to > > avoid the checks in the callers and make it robust. > > Doesn't this conflict the goal of arbitrary bio size? I don't think we ever had the goal of entirely arbitrary bio sizes, we wanted to get rid of the driver imposed limits. And I/O submitter deciding that it's not bound by BIO_MAX_PAGES is something entirely different. > I think nothing is > wrong in bcache side. The caller can allocate any size of bio, the block > layer will split the bio into proper size according to block layer > limitatio and driver limitation. If we get actual arbitrary large bios we a) assume drivers can handle bios larger than BIO_MAX_PAGES, which we've just noticed md can't b) have to handle all sorts of mempools to handle this giant size nothing that can't be be done, but it's pretty obvious that we're not there yet. And I'm not really sure it's necessarily worth it, but I'm happy to be proven wrong. > As long as bio_split can do the right > job, caller of bio allo is good. But it's pretty clear that it currently doesn't do the right job, and reducing general queue limits for a single submitter that doesn't follow the protocol isn't the way to go. The obvious fix is to make bcache behave like everyone else for now, and then look into how useful and painful it would be to move to larger bios in general.