All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <jroedel@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN
Date: Wed, 3 Dec 2014 11:27:21 +0100	[thread overview]
Message-ID: <20141203102721.GM3156@suse.de> (raw)
In-Reply-To: <20141202184648.GB32622@laptop.dumpdata.com>

On Tue, Dec 02, 2014 at 01:46:48PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 03:45:51PM +0100, Joerg Roedel wrote:
> > On Mon, Dec 01, 2014 at 03:28:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 28, 2014 at 12:29:08PM +0100, Joerg Roedel wrote:
> > > > diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
> > > > index 77dd0ad..79b2291 100644
> > > > --- a/arch/x86/kernel/pci-swiotlb.c
> > > > +++ b/arch/x86/kernel/pci-swiotlb.c
> > > > @@ -20,6 +20,14 @@ void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> > > >  {
> > > >  	void *vaddr;
> > > >  
> > > > +	/*
> > > > +	 * When booting a kdump kernel in high memory these allocations are very
> > > > +	 * likely to fail, as there are by default only 8MB of low memory to
> > > > +	 * allocate from. So disable the warnings from the allocator when this
> > > > +	 * happens.  SWIOTLB also implements fall-backs for failed allocations.
> > > > +	 */
> > > > +	flags |= __GFP_NOWARN;
> > > 
> > > Should this perhaps then have 'if (kdump_kernel)' around it since
> > > the use-case seems to be kdump related?
> > 
> > Hmm, I don't think this is entirely kdump specific. It can also be
> > triggered on a non-kdump kernel, it is just much more unlikely. But
> > maybe I should change the comment to something like:
> > 
> > 	/*
> > 	 * Don't print a warning when the first allocation attempt
> > 	 * fails. The swiotlb_alloc_coherent() function will print a
> > 	 * warning when the allocation of DMA memory ultimatly failed.
> > 	 */
> 
> Much better. Thank you.
> > 
> > This takes the kdump-specifics out of this change (in the end
> > kdump-kernel loaded high is just a case where this failure is much more
> > likely).
> 
> <nods>

Okay, thanks. I'll update the patch.


	Joerg


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

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 11:29 [PATCH 0/3] Fix kdump failures with crashkernel=high 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 [this message]
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
2014-12-03 15:19     ` WANG Chao
2015-01-06 14:51 [PATCH 0/3 v2] " Joerg Roedel
2015-01-06 14:51 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel
2015-01-23 17:03   ` Borislav Petkov
2015-01-26  3:22     ` Baoquan He
2015-01-26 11:54       ` Joerg Roedel
2015-06-05 10:29 [PATCH 0/3 v3] Fix kdump failures with crashkernel=high Joerg Roedel
2015-06-05 10:30 ` [PATCH 2/3] x86, swiotlb: Try coherent allocations with __GFP_NOWARN Joerg Roedel

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=20141203102721.GM3156@suse.de \
    --to=jroedel@suse.de \
    --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 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.