Dne Po 4. května 2015 09:06:01, Josh Boyer napsal(a):
> On Sun, May 3, 2015 at 5:25 AM, Tomáš Trnka <tomastrnka@xxxxxxx> wrote:
> > Hello,
> >
> > I have a PCI-based SATA controller (Sil3124) that chokes on PCI DAC
> > addressing, so I have to force 32-bit addressing through an IOMMU. Sadly,
> > the stock Fedora kernel falls back to SWIOTLB on this machine, which is
> > both slower (though I haven't benchmarked it) and unreliable (several
> > times I've seen the SWIOTLB overflow and go boom).
> >
> > Apparently, all I need is the AMD GART-based IOMMU implementation
> > (CONFIG_GART_IOMMU) that is currently disabled by Fedora. This means I
> > currently have to rebuild the kernel every time to re-enable it.
>
> GART_IOMMU is the really old IOMMU found in older Athlon64/Opteron
> CPUs. Most modern AMD CPUS use AMD_IOMMU, which is enabled. Do you
> have one of these older CPUs?
Yes, I have an AM3-based K10 CPU and the GART IOMMU is the only option on this
machine (the chipset predates AMD-Vi).
> > Is there any particular reason why this is disabled in Fedora (upstream
> > Kconfig default is enabled)? Given that there is probably a non-negligible
> > fraction of machines that could benefit from the GART IOMMU and the kernel
> > size impact is minimal, would it be possible to restore the upstream
> > default?
> Upstream doesn't include it in the x86_64_defconfig and it isn't
> default y. The Kconfig help text says to enable if unsure, but if you
> look at the commit log where this option was last changed, it's pretty
> discouraging.
Oops, sorry, I failed to notice that there is no "default" Kconfig line there,
the help text got me confused.
Thanks for pointing out the commit, I apparently did not dig deep enough into
kernel history.
I hate the idea of having to sacrifice ~100 MiB of perfectly good RAM just for
SWIOTLB, but if I'm the only one with this problem, saving 8K (as mentioned in
the commit message) on every Fedora kernel out there may indeed be a better
option.
2T
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
