Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757476AbYGXPIa (ORCPT ); Thu, 24 Jul 2008 11:08:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753329AbYGXPIT (ORCPT ); Thu, 24 Jul 2008 11:08:19 -0400 Received: from mx1.redhat.com ([66.187.233.31]:37931 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753546AbYGXPIS (ORCPT ); Thu, 24 Jul 2008 11:08:18 -0400 Date: Thu, 24 Jul 2008 11:07:02 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@devserv.devel.redhat.com To: James Bottomley cc: David Miller , fujita.tomonori@lab.ntt.co.jp, jens.axboe@oracle.com, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, linux-parisc@vger.kernel.org Subject: Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE In-Reply-To: <1216575211.4199.35.camel@localhost.localdomain> Message-ID: References: <1216520228.3376.33.camel@localhost.localdomain> <20080719.210737.197246608.davem@davemloft.net> <1216565545.4199.10.camel@localhost.localdomain> <20080720.102302.137955996.davem@davemloft.net> <1216575211.4199.35.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1366 Lines: 34 > > For a dumb I/O card, you advertise SG_ALL capabilities, the IOMMU > > is going to merge things as it would have anyways, and you have > > code in the driver to advance SG entries after each "dumb I/O". > > Not that dumb ... they just have a limited number of SG slots. We > wouldn't want to run them as spoon fed PIO because that really would > kill performance. > > > There is zero value to the vmerge code, the real gains are being > > realized already. > > There is value to me in my testbed, which I can't achieve any other way > (except by buying different SCSI cards). > > As I said, you can compile it out on sparc just fine. I wish to keep it > running for parisc, so I'll maintain it. If it ever bit rots out of > parisc like it has done for the other architectures, then feel free to > remove it. > > James So try to #define BIO_VMERGE_BOUNDARY 0 for Pa-Risc and tell us what performance degradation do you see (and what driver do you use and what is the I/O pattern). If you show something specific, we can consider that --- but you haven't yet told us anything, except generic talk. Mikulas -- 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/