2012/9/25 Maxim Uvarov <muvarov at gmail.com>: > In the most cases you need to boot crash kernel with nr_cpus=1 > parameter. In that case you will not allocate per cpus buffers for > other cpus. Saving dump on more the one cpu does not give any benefit. > So it's very rare case where you need such huge memory only for save > dump process. You might be looking to the problem from the work side. other. > > Maxim. > > 2012/9/25 Eric W. Biederman <ebiederm at xmission.com>: >> Cliff Wickman <cpw at sgi.com> writes: >> >>> Hi Eric, and all, >>> >>> On Mon, Sep 24, 2012 at 08:11:12PM -0700, Eric W. Biederman wrote: >>>> Cliff Wickman <cpw at sgi.com> writes: >>>> >>>> > Gentlemen, >>>> > >>>> > In dumping very large memories we are running up against the 896MB >>>> > limit in SLES11SP2 (3.0.38 kernel). >>>> >>>> Odd. That limit should be the maximum address in memory to load the >>>> crash kernel. Tha limit should have nothing to do with the dump process >>>> itself. >>>> >>>> Are you saying you need more that 512MiB reserved for the crash kernel >>>> to be able to dump all of the memory in your system? >>>> >>>> Eric >>> >>> As I noted to Eric privately, yes we need to bump up to crashkernel=1G >>> or more for some very large memories. >>> >>> As an experiment I bumped >>> +++ linux/arch/x86/kernel/setup.c >>> @@ -528,7 +528,7 @@ static inline unsigned long long get_tot >>> #ifdef CONFIG_X86_32 >>> # define CRASH_KERNEL_ADDR_MAX (512 << 20) >>> #else >>> -# define CRASH_KERNEL_ADDR_MAX (896 << 20) >>> +# define CRASH_KERNEL_ADDR_MAX (1700 << 20) >>> >>> And that seems to work. i.e. I'm currently dumping a system where >>> crashkernel=1G and it seems to be working. >>> >>> Am I just living dangerously? >> >> So fundamentally this should work. However there have been a lot of >> kinks and silly limitations in the x86 boot protocol. >> >> So it used to be that the bootloader protocol variable ramdisk_max was >> set to 896M for 32bit kernels. Because the ramdisk could not be located >> in high memory. >> >> Looking today it appears that ramdisk_max has been upped to 4G. >> >> I will let you look through the /sbin/kexec source code. >> >> As for testing I would up the limit to 4G on x86_64 and see how far >> you get. >> >> The practical question does the system still work with crashkernel=32M >> when you have raised the limit much higher. >> >> So I would test with crashkernel=1G at 2G and see if that works. If that >> works I figure that in practice all of the bugs are historical and we >> can forget them. But a sweep through the /sbin/kexec code for the magic >> number 896 might not be out of order. >> >> Eric >> >> >> >> >> >> _______________________________________________ >> kexec mailing list >> kexec at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec > > > > -- > Best regards, > Maxim Uvarov -- Best regards, Maxim Uvarov
