All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Miquel van Smoorenburg <mikevs@xs4all.net>
Cc: linux-kernel@vger.kernel.org, Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY
Date: Tue, 10 Jun 2008 12:23:47 +0200	[thread overview]
Message-ID: <20080610102347.GC19136@elte.hu> (raw)
In-Reply-To: <1212682484.4332.7.camel@n2o.xs4all.nl>


* Miquel van Smoorenburg <mikevs@xs4all.net> wrote:

> On Mon, 2008-06-02 at 12:15 +0200, Ingo Molnar wrote:
> > * Miquel van Smoorenburg <mikevs@xs4all.net> wrote:
> > 
> > > Okay, so how about this then ?
> >
> > 
> > applied to tip/pci-for-jesse for more testing. Thanks,
> 
> I've thought about it a bit more, and I think the actual patch that 
> really does what everybody wants is this one instead:

applied a delta patch version of the one below to tip/pci-for-jesse. 
Thanks,

	Ingo

> [PATCH] x86: pci-dma.c: don't always add __GFP_NORETRY to gfp
> 
> Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY
> to the allocation flags, because it wants to be reasonably
> sure not to deadlock when calling alloc_pages().
> 
> But really that should only be done in two cases:
> - when allocating memory in the lower 16 MB DMA zone.
>   If there's no free memory there, waiting or OOM killing is of no use
> - when optimistically trying an allocation in the DMA32 zone
>   when dma_mask < DMA_32BIT_MASK hoping that the allocation
>   happens to fall within the limits of the dma_mask
> 
> Also blindly adding __GFP_NORETRY to the the gfp variable might
> not be a good idea since we then also use it when calling
> dma_ops->alloc_coherent(). Clearing it might also not be a
> good idea, dma_alloc_coherent()'s caller might have set it
> on purpose. The gfp variable should not be clobbered.
> 
> Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>
> 
> --- linux-2.6.26-rc4.orig/arch/x86/kernel/pci-dma.c	2008-05-26 20:08:11.000000000 +0200
> +++ linux-2.6.26-rc4/arch/x86/kernel/pci-dma.c	2008-06-05 17:51:41.000000000 +0200
> @@ -378,6 +378,7 @@ dma_alloc_coherent(struct device *dev, s
>  	struct page *page;
>  	unsigned long dma_mask = 0;
>  	dma_addr_t bus;
> +	int noretry = 0;
>  
>  	/* ignore region specifiers */
>  	gfp &= ~(__GFP_DMA | __GFP_HIGHMEM | __GFP_DMA32);
> @@ -397,20 +398,25 @@ dma_alloc_coherent(struct device *dev, s
>  	if (dev->dma_mask == NULL)
>  		return NULL;
>  
> -	/* Don't invoke OOM killer */
> -	gfp |= __GFP_NORETRY;
> +	/* Don't invoke OOM killer or retry in lower 16MB DMA zone */
> +	if (gfp & __GFP_DMA)
> +		noretry = 1;
>  
>  #ifdef CONFIG_X86_64
>  	/* Why <=? Even when the mask is smaller than 4GB it is often
>  	   larger than 16MB and in this case we have a chance of
>  	   finding fitting memory in the next higher zone first. If
>  	   not retry with true GFP_DMA. -AK */
> -	if (dma_mask <= DMA_32BIT_MASK && !(gfp & GFP_DMA))
> +	if (dma_mask <= DMA_32BIT_MASK && !(gfp & GFP_DMA)) {
>  		gfp |= GFP_DMA32;
> +		if (dma_mask < DMA_32BIT_MASK)
> +			noretry = 1;
> +	}
>  #endif
>  
>   again:
> -	page = dma_alloc_pages(dev, gfp, get_order(size));
> +	page = dma_alloc_pages(dev,
> +		noretry ? gfp | __GFP_NORETRY : gfp, get_order(size));
>  	if (page == NULL)
>  		return NULL;
>  
> 

  parent reply	other threads:[~2008-06-10 10:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-26 23:49 [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY Miquel van Smoorenburg
2008-05-26 23:49 ` Miquel van Smoorenburg
2008-05-27  8:03 ` Ingo Molnar
2008-05-27  8:03   ` Ingo Molnar
2008-05-27  8:47 ` Andrew Morton
2008-05-27  8:47   ` Andrew Morton
2008-05-27  9:35   ` Miquel van Smoorenburg
2008-05-27  9:35     ` Miquel van Smoorenburg
2008-05-28  2:47   ` Andi Kleen
2008-05-28  2:47     ` Andi Kleen
2008-05-28  8:31     ` Miquel van Smoorenburg
2008-05-28  8:31       ` Miquel van Smoorenburg
2008-05-28  8:40       ` Andrew Morton
2008-05-28  8:40         ` Andrew Morton
2008-05-28 12:54         ` Andi Kleen
2008-05-28 12:54           ` Andi Kleen
2008-06-02 10:15       ` Ingo Molnar
2008-06-02 10:15         ` Ingo Molnar
     [not found]         ` <1212682484.4332.7.camel@n2o.xs4all.nl>
2008-06-10 10:23           ` Ingo Molnar [this message]
2008-06-10 17:14             ` Jesse Barnes
2008-06-11 14:26               ` Miquel van Smoorenburg
2008-06-26 11:38               ` Ingo Molnar
2008-07-02  2:39                 ` Jesse Barnes
2008-07-02  2:46                   ` Yinghai Lu
2008-07-02  2:48                     ` Jesse Barnes

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=20080610102347.GC19136@elte.hu \
    --to=mingo@elte.hu \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikevs@xs4all.net \
    /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.