mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: WANG Chao <chaowang@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] Fix kdump failures with crashkernel=high
Date: Wed, 3 Dec 2014 11:35:06 +0100	[thread overview]
Message-ID: <20141203103506.GN3156@suse.de> (raw)
In-Reply-To: <20141203040123.GB23163@dhcp-17-37.nay.redhat.com>

Hi,

On Wed, Dec 03, 2014 at 12:01:23PM +0800, WANG Chao wrote:
>From your experience It seems like swiotlb isn't working well with
> crashkernel=X,high alone. What about using crashkernel=X,low with
> crashkernel=X,high? Is there any reason you have to use
> crashkernel=X,high alone?

Sure, when I specify an additional crashkernel=X,low then I can get
things to work this way too. But my patch-set is about changing the
default, since the failure was seen on common server systems with the
defaults.

> crashkernel=X,high shouldn't automatically reserve 72M low at the first
> place. Now it's going insane if you increase it to 256M by default.

How should a kernel without some low memory (which has only memory above
4G available) handle any 32bit DMA devices? There would be no way to
allocate DMA-able memory for those devices.

And as I said, if people prefer it I can change the patch-set so that
the amount of low-memory allocated is subtracted from the amount of
high-memory. This way the overall memory usage for kdump would stay the
same while changing the defaults to work on more systems.


	Joerg


  reply	other threads:[~2014-12-03 10:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 11:29 Joerg Roedel
2014-11-28 11:29 ` [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent Joerg Roedel
2014-12-01 20:28   ` Konrad Rzeszutek Wilk
2014-12-02 14:41     ` Joerg Roedel
2014-12-02 18:46       ` Konrad Rzeszutek Wilk
2014-12-03 10:26         ` Joerg Roedel
2014-12-11 19:08           ` Konrad Rzeszutek Wilk
2014-11-28 11:29 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel
2014-12-01 20:28   ` Konrad Rzeszutek Wilk
2014-12-02 14:45     ` Joerg Roedel
2014-12-02 18:46       ` Konrad Rzeszutek Wilk
2014-12-03 10:27         ` Joerg Roedel
2014-11-28 11:29 ` [PATCH 3/3] x86, crash: Allocate enough low-mem when crashkernel=high Joerg Roedel
2014-12-02 11:30 ` [PATCH 0/3] Fix kdump failures with crashkernel=high Baoquan He
2014-12-02 14:56   ` Joerg Roedel
2014-12-03  4:01 ` WANG Chao
2014-12-03 10:35   ` Joerg Roedel [this message]
2014-12-03 15:19     ` WANG Chao

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=20141203103506.GN3156@suse.de \
    --to=jroedel@suse.de \
    --cc=chaowang@redhat.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome