diff options
author | Kevin VanMaren <kvanmaren@lnxi.com> | 2006-02-03 21:51:32 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-02-04 16:43:14 -0800 |
commit | a1002a48e1af5ff8d02bfe79536e6fce3a0ec369 (patch) | |
tree | 0e6988d51b37185dac2e9b92d86091fb224c75ff /arch/x86_64/mm | |
parent | 1de6bf33bc4601d856c286ad5c7d515468e24bbb (diff) | |
download | op-kernel-dev-a1002a48e1af5ff8d02bfe79536e6fce3a0ec369.zip op-kernel-dev-a1002a48e1af5ff8d02bfe79536e6fce3a0ec369.tar.gz |
[PATCH] x86_64: When allocation of merged SG lists fails in the IOMMU don't merge
[ AK: I redid Kevin's fix to be simpler, but the idea and original
analysis of the problem is from Kevin]
This avoid allocation failures on some SATA systems like Nvidia CK8
when the IOMMU gets fragmented. Modern SATA devices have quite large queues
(128 entries) and the FS with ext2/3 is good enough now that it often
passes whole 128 page sg lists down to the driver. These require
512K of continuous free space in the IOMMU aperture to map when merged.
When the IOMMU is fragmented this could lead to spurious IO errors
due to failing mappings.
Short term fix is to just try to map the SG list again unmerged
page by page - this way fragmentation doesn't matter anymore.
The code for that was already there, but it just wasn't enabled for the
merge case.
According to Kevin at least the Nvidia device doesn't seem to benefit
from merging much anyways, so the only slowdown is from trying
to do an unnecessary merge attempt.
Kevin plans to implement better fragmentation avoidance in the future,
but that wouldn't be 2.6.16 material.
TBD: should add some statistic counters to count how often that really
happens.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'arch/x86_64/mm')
0 files changed, 0 insertions, 0 deletions