Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756204AbcC2IPy (ORCPT ); Tue, 29 Mar 2016 04:15:54 -0400 Received: from zimbra13.linbit.com ([212.69.166.240]:49962 "EHLO zimbra13.linbit.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbcC2IPv (ORCPT ); Tue, 29 Mar 2016 04:15:51 -0400 X-Greylist: delayed 385 seconds by postgrey-1.27 at vger.kernel.org; Tue, 29 Mar 2016 04:15:51 EDT Date: Tue, 29 Mar 2016 10:09:21 +0200 From: Lars Ellenberg To: Christoph Hellwig Cc: Ming Lei , Jens Axboe , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Al Viro , Anton Altaparmakov , xfs@oss.sgi.com, Dave Chinner , drbd-dev@lists.linbit.com, Philipp Reisner , Boaz Harrosh Subject: Re: [PATCH 7/8] block: drbd: avoid to use BIO_MAX_SIZE Message-ID: <20160329080921.GG15579@soda.linbit> Mail-Followup-To: Christoph Hellwig , Ming Lei , Jens Axboe , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Al Viro , Anton Altaparmakov , xfs@oss.sgi.com, Dave Chinner , drbd-dev@lists.linbit.com, Philipp Reisner , Boaz Harrosh References: <1458627149-12988-1-git-send-email-ming.lei@canonical.com> <1458627149-12988-8-git-send-email-ming.lei@canonical.com> <20160329073124.GH18920@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160329073124.GH18920@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1286 Lines: 37 On Tue, Mar 29, 2016 at 12:31:24AM -0700, Christoph Hellwig wrote: > On Tue, Mar 22, 2016 at 02:12:28PM +0800, Ming Lei wrote: > > drbd is the only user of BIO_MAX_SIZE, so use BIO_MAX_PAGES > > instead. > > That whole code block looks completely bogus to me, although your patch > doesn't make it any worse. > > I/O size for a network protocol shouldn't dependend on the number of > vectors in a kernel internal structure. That's correct. But we needed some limit there. Initially, up until I changed it like six years ago iirc, the receiving side would receive into a single bio. So limiting us to what a single bio could usually handle seemed like a good idea at the time. Today, we should be able to handle 128 MiB easily, maybe more. But that would require a protocol bump to stay backwards compatible. The part about "architecture not supported", if our limit (1 MiB) is bigger than the "system" limit: Never met that in real life. Probably not even possible. Just a paranoia on my side: what if. If that would have happened somewhere, on some strange architecture or configuration, I wanted to know about that. Best way: don't even compile. > Well, getting rid of BIO_MAX_SIZE is worth it, so: > > Reviewed-by: Christoph Hellwig Thanks, Lars Ellenberg