Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448Ab2E1XCV (ORCPT ); Mon, 28 May 2012 19:02:21 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:63907 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751928Ab2E1XCT (ORCPT ); Mon, 28 May 2012 19:02:19 -0400 Date: Tue, 29 May 2012 08:02:08 +0900 From: Tejun Heo To: Mikulas Patocka Cc: Alasdair G Kergon , Kent Overstreet , Mike Snitzer , linux-kernel@vger.kernel.org, linux-bcache@vger.kernel.org, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, axboe@kernel.dk, yehuda@hq.newdream.net, vgoyal@redhat.com, bharrosh@panasas.com, sage@newdream.net, drbd-dev@lists.linbit.com, Dave Chinner , tytso@google.com, "Martin K. Petersen" Subject: Re: [PATCH v3 14/16] Gut bio_add_page() Message-ID: <20120528230208.GA20954@dhcp-172-17-108-109.mtv.corp.google.com> References: <1337977539-16977-1-git-send-email-koverstreet@google.com> <1337977539-16977-15-git-send-email-koverstreet@google.com> <20120525204651.GA24246@redhat.com> <20120525210944.GB14196@google.com> <20120525223937.GF5761@agk-dp.fab.redhat.com> <20120528202839.GA18537@dhcp-172-17-108-109.mtv.corp.google.com> <20120528213839.GB18537@dhcp-172-17-108-109.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120528213839.GB18537@dhcp-172-17-108-109.mtv.corp.google.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1021 Lines: 26 (cc'ing Martin K. Petersen, hi!) On Tue, May 29, 2012 at 06:38:39AM +0900, Tejun Heo wrote: > > With this patchset, you don't have to expose all the limits. You can > > expose just a few most useful limits to avoid bio split in the cases > > described above. > > Yeah, if that actually helps, sure. From what I read, dm is already > (ab)using merge_bvec_fn() like that anyway. i thought a bit more about it and the only thing which makes sense to me is exposing the stripe granularity for striped devices - ie. something which says "if you go across this boundary, the performance characteristics including latency might get affected", which should fit nicely with the rest of topology information. Martin, adding that shouldn't be difficult, right? Thanks. -- tejun -- 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/