Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932220AbbHJQmG (ORCPT ); Mon, 10 Aug 2015 12:42:06 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:17134 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754090AbbHJQmC (ORCPT ); Mon, 10 Aug 2015 12:42:02 -0400 To: Ming Lin Cc: Mike Snitzer , axboe@fb.com, Christoph Hellwig , "Martin K. Petersen" , device-mapper development , Ming Lei , Christoph Hellwig , Alasdair Kergon , Lars Ellenberg , Philip Kelleher , Kent Overstreet , Nitin Gupta , Ming Lin , Oleg Drokin , Al Viro , Jens Axboe , Andreas Dilger , Geoff Levand , Jiri Kosina , lkml , Jim Paris , Minchan Kim , Dongsu Park , drbd-user@lists.linbit.com, Joe Thornber Subject: Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios From: "Martin K. Petersen" Organization: Oracle Corporation References: <20150731213831.GA16464@redhat.com> <1438412290.26596.14.camel@hasee> <20150801163356.GA21478@redhat.com> <1439099990.7880.0.camel@hasee> <20150809064128.GB2436@infradead.org> <1439103347.7880.3.camel@hasee> <20150809070128.GA25739@infradead.org> <1439104707.7880.8.camel@hasee> <20150810150216.GA22719@redhat.com> <1439223252.27204.10.camel@hasee> Date: Mon, 10 Aug 2015 12:40:52 -0400 In-Reply-To: <1439223252.27204.10.camel@hasee> (Ming Lin's message of "Mon, 10 Aug 2015 09:14:12 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1109 Lines: 28 >>>>> "Ming" == Ming Lin writes: Ming, Ming> I also prefer using MAX_BIO_SECTORS. Otherwise, we may have non Ming> page size aligned splits. This does not matter for write same and discard since there is only a single logical block of payload. Also, given limitations in SATA we're always issuing 2GB-32KB sized discards. Rounding those down to an even 1GB would impact performance. I am sympathetic to wanting to issue I/Os that are aligned to powers of two. But for most devices this matters little since the additional cost is limited to misaligned head and tail blocks. One thing that may be worth considering is switching bi_size from bytes to blocks for REQ_FS. That would give us some headroom without increasing bi_size beyond 32 bits. But I'm not entirely sure it's worth the pain. -- Martin K. Petersen Oracle Linux Engineering -- 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/