Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754307AbYGMNvS (ORCPT ); Sun, 13 Jul 2008 09:51:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753277AbYGMNvF (ORCPT ); Sun, 13 Jul 2008 09:51:05 -0400 Received: from one.firstfloor.org ([213.235.205.2]:42458 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbYGMNvE (ORCPT ); Sun, 13 Jul 2008 09:51:04 -0400 Message-ID: <487A083F.9010301@firstfloor.org> Date: Sun, 13 Jul 2008 15:50:55 +0200 From: Andi Kleen User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Mikulas Patocka CC: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests References: <87iqvb2skz.fsf@basil.nowhere.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1632 Lines: 41 Mikulas Patocka wrote: >> Mikulas Patocka writes: >> >>> I'm getting crashes with InitIO A100u2w controller on Sparc64 (I had >>> to fix the endianity issues in the driver, but that's unrelated). >> >> x86-64 (and powerpc) solved this a long time ago by only doing >> opportunistic merging: as in don't announce to the block layer >> that you can merge, but try to merge anyways. This way SG lists >> are not necessarily filled completely, but it's still better >> than overflowing them in some rare cases. >> >> -Andi > > There's option "biomerge" that enables that feature. I'm wondering, if > there's some situation when it should be used. It would only help if your SG hardware is slower at processing merges than the IOMMU. We found some long ago that was (old MPT Fusion) that gained a few percent on some benchmarks, but that might be quite different depending on the particular IO controller and chipset. Also biomerge was used for the AMD K8 GART "IOMMU" which is relatively slow, the situation on more modern x86 IOMMUs might be different. Also the GART IOMMU is small and fragmentation is more likely. The situation on the more modern real x86 IOMMU (like in newer Intel or IBM chipsets) might be also different. Still I would expect that modern IO controllers are typically fast enough at processing SG lists that it shouldn't matter much. -Andi -- 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/