Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it
From: Eric W. Biederman
Date: Fri Jan 04 2013 - 17:47:33 EST
Shuah Khan <shuahkhan@xxxxxxxxx> writes:
> On Fri, Jan 4, 2013 at 3:10 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan <shuahkhan@xxxxxxxxx> wrote:
>>> Pani'cing the system doesn't sound like a good option to me in this
>>> case. This change to disable swiotlb is made for kdump. However, with
>>> this change several system fail to boot, unless crashkernel_low=72M is
>> this patchset is new feature to put second kdump kernel above 4G.
> I understand this is just one of the patches to implement the new
> kdump feature. However, I think regression on existing behavior with a
> panic is a bit of a big hammer. Thie change causes panic on systems
> even when kdump is not enabled, if I understand it correctly.
> Granted kdump gets enabled by several distros, but it is not a
> required feature. However, expecting system to boot with devices that
> require swiotlb fully functioning is a basic feature. So I would argue
> that not breaking the basic functionality is a higher priority over
> enabling kdump in this case.
Yinghai Lu it looks like your autodetection of the problem case in this
patch is problematic and needs a rethink. My quick skim says you are
trying to detect failure too early in the code. Furthermore having
kexec on panic sized magic comments without explanation is wrong.
Shuah Khan this is motivated by kdump. However a correct implementation
should be about dealing with the case when there is simply not enough
memory available below 4G for bounce buffers.
If a device needs an iommu, and swiotlb is the only iommu option, and
there is not enough memory below 4G panic'ing is entirely reasonable.
Do I read this discussion right that we are waisting 64M on systems
that have the swiotlb code but don't use the swiotlb?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/