Messages in this thread | | | Date | Fri, 15 Nov 2013 14:24:25 -0800 | Subject | Re: [PATCH 0/3] Early use of boot service memory | From | Yinghai Lu <> |
| |
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>> I have one system with 6TiB memory, kdump does not work even >> crashkernel=512M in legacy mode. ( it only work on system with >> 4.5TiB). > > Recently I tested one system with 6TB of memory and dumped successfully > with 512MB reserved under 896MB. Also I have heard reports of successful > dump of 12TB system with 512MB reserved below 896MB (due to cyclic > mode of makedumpfile). > > So with newer releases only reason one might want to reserve more > memory is that it might provide speed benefits. We need more testing > to quantify this.
You may need bunch of PCIe cards installed.
The system with 6TiB + 16 PCIe cards, second kernel OOM. The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore dumped.
> >> --- first kernel can reserve the 512M under 896M, second kernel will >> OOM as it load driver for every pci devices... >> >> So why would RH guys not spend some time on optimizing your kdump initrd >> build scripts and only put dump device related driver in it? > > Try latest Fedora and that's what we do. Now we have moved to dracut > based initramfs generation and we tell dracut that build initramfs for > host and additional dump destination and dracut builds it for those only. > I think there might be scope for further optimization, but I don't think > that's the problem any more.
Good. Assume that will be in RHEL 7.
> > So issue remains that crashkernel=X,high is not a good default choice > because it consumes extra 72M which we don't have to.
then if it falls into 896~4G, user may still need to update kexec-tools ?
Thanks
Yinghai
| |