[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487A083F.9010301@firstfloor.org>
Date: Sun, 13 Jul 2008 15:50:55 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Mikulas Patocka <mpatocka@...hat.com>
CC: sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Mikulas Patocka wrote:
>> Mikulas Patocka <mpatocka@...hat.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists