All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jay Lan <jlan@sgi.com>
Cc: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>, kexec@lists.infradead.org
Subject: Re: problems in kdump kernel if 'maxcpus=1' not specified?
Date: Wed, 16 Jul 2008 11:12:40 -0400	[thread overview]
Message-ID: <20080716151240.GB711@redhat.com> (raw)
In-Reply-To: <487D49DC.8040209@sgi.com>

On Tue, Jul 15, 2008 at 06:07:40PM -0700, Jay Lan wrote:
> Are there known problems if you boot up kdump kernel with
> multipl cpus?
> 

I had run into one issue and that was some system would get reset and 
jump to BIOS.

The reason was that kdump kernel can boot on a non-boot cpu. When it
tries to bring up other cpus it sends INIT and a non-boot cpu sending
INIT to "boot" cpu was not acceptable (as per intel documentation) and 
it re-initialized the system.

I am not sure how many systems are affected with this behavior. Hence
the reason for using maxcpus=1.

> It takes unacceptably long time to run makedumpfile in
> saving dump at a huge memory system. In my testing it
> took 16hr25min to run create_dump_bitmap() on a 1TB system.
> Pfn's are processed sequentially with single cpu. We
> certainly can use multipl cpus here ;)

This is certainly very long time. How much memory have you reserved for
kdump kernel?

I had run some tests on a x86_64 128GB RAM system and it took me 4 minutes
to filter and save the core (maximum filtering level of 31). I had
reserved 128MB of memory for kdump kernel.

I think something else is seriously wrong here. 1 TB is almost 10 times of
128GM and even if time scales linearly it should not take more than
40mins.

You need to dive deeper to find out what is taking so much of time.

CCing kenichi.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2008-07-16 15:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-16  1:07 problems in kdump kernel if 'maxcpus=1' not specified? Jay Lan
2008-07-16 15:12 ` Vivek Goyal [this message]
2008-07-16 15:25   ` Neil Horman
2008-07-16 16:23     ` Vivek Goyal
2008-07-16 17:03       ` Neil Horman
2008-07-16 19:16         ` Jay Lan
2008-07-17  4:59           ` Ken'ichi Ohmichi
2008-07-17  6:35             ` [PATCH] makedumpfile: Shrink the time for creating 1st-bitmap (Re: problems in kdump kernel if 'maxcpus=1' not specified?) Ken'ichi Ohmichi
2008-07-17 17:09               ` Jay Lan
2008-07-18  4:00                 ` Ken'ichi Ohmichi
2008-07-18 15:57                   ` Jay Lan
2008-07-16 18:00       ` problems in kdump kernel if 'maxcpus=1' not specified? Jay Lan
2008-07-16 15:26   ` Bernhard Walle
2008-07-16 16:34     ` Vivek Goyal
2008-07-16 16:45       ` Bernhard Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080716151240.GB711@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=jlan@sgi.com \
    --cc=kexec@lists.infradead.org \
    --cc=oomichi@mxs.nes.nec.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.