On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> wrote: > On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote: >> [snip] >> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but >> > > > I hope that adding "numa=off" to kernel command line should also work. >> > > >> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was >> > > my initial thought process as well, but I am not sure if this will >> > > cause any regressions on aarch64 systems which use crashdump feature. >> > >> > It should be fine since we use numa=off by default for all other arches >> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save >> > mm component memory usage. >> > >> >> Forgot to say I means in RHEL and Fedora we use numa=off for kdump.. > > Thank you for the clarification. > (It might be better to make numa off automatically if maxcpus == 0 (and 1?).) > Not sure if we can leave this to the distribution-specific kdump scripts (as the crashkernel boot can be held up for sufficient time and may appear stuck). The distribution scripts may be different (for e.g. ubuntu and RHEL/fedora) across distributions and may have different bootarg options. So how about considering a kernel fix only which doesn't require relying on changing the distribution-specific kdump scripts, as we should avoid introducing a regression while trying to fix a regression :) Just my 2 cents. Thanks, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
