Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759342AbcDERbh (ORCPT ); Tue, 5 Apr 2016 13:31:37 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:42260 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752023AbcDERbg (ORCPT ); Tue, 5 Apr 2016 13:31:36 -0400 Date: Tue, 5 Apr 2016 10:31:34 -0700 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , Linux Kernel Mailing List , linux-block@vger.kernel.org, Boaz Harrosh , Kent Overstreet , Shaohua Li , "open list:BCACHE (BLOCK LAYER CACHE)" , "open list:SOFTWARE RAID (Multiple Disks) SUPPORT" Subject: Re: [PATCH 11/27] bcache: io.c: use bio_set_vec_table Message-ID: <20160405173134.GC31055@infradead.org> References: <1459857443-20611-1-git-send-email-tom.leiming@gmail.com> <1459857443-20611-12-git-send-email-tom.leiming@gmail.com> <20160405124902.GA11986@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 1452 Lines: 27 On Tue, Apr 05, 2016 at 11:24:30PM +0800, Ming Lei wrote: > - bio can be embedded into one biger instance, which is often allocated > dynamically, so one extra allocation for bio can be avoided. We can also do this the other way around with the bios front_pad, which avoid the caller poking into bio details. > - we should support arbitrary bio size by this way, at least bio_add_page() > supports this usage. Also code gets lots of simplication with arbitrary bio > size support, such as prio_io(): bcache There is no reason for not supporting huge bios in the core bio code, in fact using bio_kmalloc you can already allocate huges bios dynamically right now. Except that you can't really use it, because the layers below don't expect that. Bios based drivers expect to be able to call bio_clone and friends called on bios passed to them, and might also make assumptions about the max number of bios segments for now. > BTW, the root cause for bcache crash still isn't clear now because > blk_bio_segment_split() should split big bio into proper size with > all queue's limits. Maybe the max segment limit isn't figured out correctly. The root cause is pretty simple: The queue limits matter for request based drivers, which are the only ones getting bios > BIO_MAX_PAGES except for the buggy bcache use case. You'll need to either adjust the limit for all bio based drivers to or get rid of that one magic caller not playing by the rules.