[PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Miquel van Smoorenburg]

Please consider the below patch for 2.6.26 (can somebody from the
x86 team pick this up please? Thank you)



[PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

arch/x86/kernel/pci-dma.c::dma_alloc_coherent() adds __GFP_NORETRY to
the gfp flags before calling alloc_pages() to prevent the oom killer
from running.

This has the expected side effect that that alloc_pages() doesn't
retry anymore. Not really a problem for dma_alloc_coherent(.. GFP_ATOMIC)
which is the way most drivers use it (through pci_alloc_consistent())
but drivers that call dma_alloc_coherent(.. GFP_KERNEL) directly can get
unexpected failures.

Until we have the mask allocator, use a new flag __GFP_NO_OOM
instead of __GFP_NORETRY.

Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl>

diff -ruN linux-2.6.26-rc3.orig/arch/x86/kernel/pci-dma.c linux-2.6.26-rc3/arch/x86/kernel/pci-dma.c
--- linux-2.6.26-rc3.orig/arch/x86/kernel/pci-dma.c	2008-05-18 23:36:41.000000000 +0200
+++ linux-2.6.26-rc3/arch/x86/kernel/pci-dma.c	2008-05-22 20:42:10.000000000 +0200
@@ -398,7 +398,7 @@
 		return NULL;
 
 	/* Don't invoke OOM killer */
-	gfp |= __GFP_NORETRY;
+	gfp |= __GFP_NO_OOM;
 
 #ifdef CONFIG_X86_64
 	/* Why <=? Even when the mask is smaller than 4GB it is often
diff -ruN linux-2.6.26-rc3.orig/include/linux/gfp.h linux-2.6.26-rc3/include/linux/gfp.h
--- linux-2.6.26-rc3.orig/include/linux/gfp.h	2008-05-18 23:36:41.000000000 +0200
+++ linux-2.6.26-rc3/include/linux/gfp.h	2008-05-22 21:17:36.000000000 +0200
@@ -43,6 +43,7 @@
 #define __GFP_REPEAT	((__force gfp_t)0x400u)	/* See above */
 #define __GFP_NOFAIL	((__force gfp_t)0x800u)	/* See above */
 #define __GFP_NORETRY	((__force gfp_t)0x1000u)/* See above */
+#define __GFP_NO_OOM	((__force gfp_t)0x2000u)/* Don't invoke oomkiller */
 #define __GFP_COMP	((__force gfp_t)0x4000u)/* Add compound page metadata */
 #define __GFP_ZERO	((__force gfp_t)0x8000u)/* Return zeroed page on success */
 #define __GFP_NOMEMALLOC ((__force gfp_t)0x10000u) /* Don't use emergency reserves */
diff -ruN linux-2.6.26-rc3.orig/mm/page_alloc.c linux-2.6.26-rc3/mm/page_alloc.c
--- linux-2.6.26-rc3.orig/mm/page_alloc.c	2008-05-18 23:36:41.000000000 +0200
+++ linux-2.6.26-rc3/mm/page_alloc.c	2008-05-22 17:39:12.000000000 +0200
@@ -1583,7 +1583,8 @@
 					zonelist, high_zoneidx, alloc_flags);
 		if (page)
 			goto got_pg;
-	} else if ((gfp_mask & __GFP_FS) && !(gfp_mask & __GFP_NORETRY)) {
+	} else if ((gfp_mask & __GFP_FS) &&
+			!(gfp_mask & (__GFP_NORETRY|__GFP_NO_OOM))) {
 		if (!try_set_zone_oom(zonelist, gfp_mask)) {
 			schedule_timeout_uninterruptible(1);
 			goto restart;

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Ingo Molnar]

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

> Please consider the below patch for 2.6.26 (can somebody from the x86 
> team pick this up please? Thank you)

looks good to me in principle - but it should go via -mm as it touches 
mm/page_alloc.c. Andrew: this fix is for v2.6.26.

	Ingo

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Andrew Morton]

On Tue, 27 May 2008 01:49:47 +0200 Miquel van Smoorenburg <mikevs@xs4all.net> wrote:

> Please consider the below patch for 2.6.26 (can somebody from the
> x86 team pick this up please? Thank you)
> 
> 
> 
> [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY
> 
> arch/x86/kernel/pci-dma.c::dma_alloc_coherent() adds __GFP_NORETRY to
> the gfp flags before calling alloc_pages() to prevent the oom killer
> from running.

Now, why does dma_alloc_coherent() do that?

If __GFP_FS is cleared (most cases) then we won't be calling
out_of_memory() anyway.

If __GFP_FS _is_ set then setting __GFP_NORETRY will do much more than
avoiding oom-killings.  It will prevent the page allocator from
retrying and will cause the problems which one assumes (without
evidence :() you have observed.

So...  why not just remove the setting of __GFP_NORETRY?  Why is it
wrong to oom-kill things in this case?

> This has the expected side effect that that alloc_pages() doesn't
> retry anymore. Not really a problem for dma_alloc_coherent(.. GFP_ATOMIC)
> which is the way most drivers use it (through pci_alloc_consistent())
> but drivers that call dma_alloc_coherent(.. GFP_KERNEL) directly can get
> unexpected failures.
> 
> Until we have the mask allocator, use a new flag __GFP_NO_OOM
> instead of __GFP_NORETRY.
> 

But this change increases the chances of a caller getting stuck in the
page allocator for ever, unable to make progress?

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Miquel van Smoorenburg]

On Tue, 2008-05-27 at 01:47 -0700, Andrew Morton wrote:
> On Tue, 27 May 2008 01:49:47 +0200 Miquel van Smoorenburg <mikevs@xs4all.net> wrote:
> 
> > Please consider the below patch for 2.6.26 (can somebody from the
> > x86 team pick this up please? Thank you)
> > 
> > 
> > 
> > [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY
> > 
> > arch/x86/kernel/pci-dma.c::dma_alloc_coherent() adds __GFP_NORETRY to
> > the gfp flags before calling alloc_pages() to prevent the oom killer
> > from running.
> 
> Now, why does dma_alloc_coherent() do that?
> 
> If __GFP_FS is cleared (most cases) then we won't be calling
> out_of_memory() anyway.
> 
> If __GFP_FS _is_ set then setting __GFP_NORETRY will do much more than
> avoiding oom-killings.  It will prevent the page allocator from
> retrying and will cause the problems which one assumes (without
> evidence :() you have observed.

Ah right, this was discussed in a different thread on linux-kernel /
linux-mm. Message id <20080521113028.GA24632@xs4all.net>  or see
http://lkml.org/lkml/2008/5/21/131

> So...  why not just remove the setting of __GFP_NORETRY?  Why is it
> wrong to oom-kill things in this case?

This was the first thing I proposed, since it was already that way in
pci-dma_32.c, the __GFP_NORETRY was only added in pci-dma_64.c . Hence I
found out about this when moving boxes to a 64 bit kernel. But in
2.6.26, those two were merged.

> 
> > This has the expected side effect that that alloc_pages() doesn't
> > retry anymore. Not really a problem for dma_alloc_coherent(.. GFP_ATOMIC)
> > which is the way most drivers use it (through pci_alloc_consistent())
> > but drivers that call dma_alloc_coherent(.. GFP_KERNEL) directly can get
> > unexpected failures.
> > 
> > Until we have the mask allocator, use a new flag __GFP_NO_OOM
> > instead of __GFP_NORETRY.
> > 
> 
> But this change increases the chances of a caller getting stuck in the
> page allocator for ever, unable to make progress?

Another bandaid fix I proposed was this:

diff -ruN linux-2.6.26-rc3.orig/arch/x86/kernel/pci-dma.c linux-2.6.26-rc3/arch/x86/kernel/pci-dma.c
--- linux-2.6.26-rc3.orig/arch/x86/kernel/pci-dma.c	2008-05-18 23:36:41.000000000 +0200
+++ linux-2.6.26-rc3/arch/x86/kernel/pci-dma.c	2008-05-22 21:21:37.000000000 +0200
@@ -398,7 +398,8 @@
 		return NULL;
 
 	/* Don't invoke OOM killer */
-	gfp |= __GFP_NORETRY;
+	if (!(gfp & __GFP_WAIT))
+		gfp |= __GFP_NORETRY;
 
 #ifdef CONFIG_X86_64
 	/* Why <=? Even when the mask is smaller than 4GB it is often

This will at least make sure that when called with GFP_KERNEL, __GFP_NORETRY
is not set, while it will be set with GFP_ATOMIC.

But I concluded from the earlier discussion that there was consensus about
__GFP_NO_OOM , so I sent this patch. Now I'm most definitely not an
expert, in fact pretty ignorant really, so if there are serious objections
or a better solution, please drop this patch.

I do think the issue should still be fixed.

The minimum would be to surround the gfp |= __GFP_NORETRY with
#ifdef CONFIG_X86_64 so that at least 32 bit doesn't regress
in 2.6.26

However as dpt_i2o in 2.6.26 works on 64 bit systems now and
it calls dma_alloc_coherent(.. GFP_KERNEL) I'm afraid it might
cause instability with that driver on x86_64 (that's my main
worry. tw_cli crashing is merely inconvenient).

Mike.

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Andi Kleen]

> So...  why not just remove the setting of __GFP_NORETRY?  Why is it
> wrong to oom-kill things in this case?

When the 16MB zone overflows (which can be common in some workloads)
calling the OOM killer is pretty useless because it has barely any 
real user data [only exception would be the "only 16MB" case Alan
mentioned]. Killing random processes in this case is bad. 

I think for 16MB __GFP_NORETRY is ok because there should be 
nothing freeable in there so looping is useless. Only exception would be the 
"only 16MB total" case again but I'm not sure 2.6 supports that at all
on x86.

On the other hand d_a_c() does more allocations than just 16MB, especially
on 64bit and the other zones need different strategies.


> But this change increases the chances of a caller getting stuck in the
> page allocator for ever, unable to make progress?

At least for much longer, yes I am somewhat worried about this too.

Sometimes a OOM regression test suite would be really nice.

-Andi

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Miquel van Smoorenburg]

On Wed, 2008-05-28 at 04:47 +0200, Andi Kleen wrote:
> > So...  why not just remove the setting of __GFP_NORETRY?  Why is it
> > wrong to oom-kill things in this case?
> 
> When the 16MB zone overflows (which can be common in some workloads)
> calling the OOM killer is pretty useless because it has barely any 
> real user data [only exception would be the "only 16MB" case Alan
> mentioned]. Killing random processes in this case is bad. 
> 
> I think for 16MB __GFP_NORETRY is ok because there should be 
> nothing freeable in there so looping is useless. Only exception would be the 
> "only 16MB total" case again but I'm not sure 2.6 supports that at all
> on x86.
> 
> On the other hand d_a_c() does more allocations than just 16MB, especially
> on 64bit and the other zones need different strategies.

Okay, so how about this then ?

--- 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-05-28 10:27:41.000000000 +0200
@@ -397,9 +397,6 @@
 	if (dev->dma_mask == NULL)
 		return NULL;
 
-	/* Don't invoke OOM killer */
-	gfp |= __GFP_NORETRY;
-
 #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
@@ -410,7 +407,9 @@
 #endif
 
  again:
-	page = dma_alloc_pages(dev, gfp, get_order(size));
+	/* Don't invoke OOM killer or retry in lower 16MB DMA zone */
+	page = dma_alloc_pages(dev,
+		(gfp & GFP_DMA) ? gfp | __GFP_NORETRY : gfp, get_order(size));
 	if (page == NULL)
 		return NULL;
 

Mike.

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Andrew Morton]

On Wed, 28 May 2008 10:31:25 +0200 Miquel van Smoorenburg <mikevs@xs4all.net> wrote:

> > When the 16MB zone overflows (which can be common in some workloads)
> > calling the OOM killer is pretty useless because it has barely any 
> > real user data [only exception would be the "only 16MB" case Alan
> > mentioned]. Killing random processes in this case is bad. 
> > 
> > I think for 16MB __GFP_NORETRY is ok because there should be 
> > nothing freeable in there so looping is useless. Only exception would be the 
> > "only 16MB total" case again but I'm not sure 2.6 supports that at all
> > on x86.
> > 
> > On the other hand d_a_c() does more allocations than just 16MB, especially
> > on 64bit and the other zones need different strategies.
> 
> Okay, so how about this then ?
> 
> --- 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-05-28 10:27:41.000000000 +0200
> @@ -397,9 +397,6 @@
>  	if (dev->dma_mask == NULL)
>  		return NULL;
>  
> -	/* Don't invoke OOM killer */
> -	gfp |= __GFP_NORETRY;
> -
>  #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
> @@ -410,7 +407,9 @@
>  #endif
>  
>   again:
> -	page = dma_alloc_pages(dev, gfp, get_order(size));
> +	/* Don't invoke OOM killer or retry in lower 16MB DMA zone */
> +	page = dma_alloc_pages(dev,
> +		(gfp & GFP_DMA) ? gfp | __GFP_NORETRY : gfp, get_order(size));
>  	if (page == NULL)
>  		return NULL;

I guess that's more specifally solving that-which-we-wish-to-solve.

Formally we should be testing __GFP_DMA here, not GFP_DMA - just the
zone selector field.  They're presently equal, but someone could
legitimately come along and do

#define GFP_DMA (__GFP_DMA|__GFP_HIGH)

or similar.

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Andi Kleen]

> > -	page = dma_alloc_pages(dev, gfp, get_order(size));
> > +	/* Don't invoke OOM killer or retry in lower 16MB DMA zone */
> > +	page = dma_alloc_pages(dev,
> > +		(gfp & GFP_DMA) ? gfp | __GFP_NORETRY : gfp, get_order(size));
> >  	if (page == NULL)
> >  		return NULL;
> 
> I guess that's more specifally solving that-which-we-wish-to-solve.

Then the allocator could still be stuck in ZONE_DMA32 on 64bit.

Also d_a_c() does one "speculative" allocation, as in an allocation
where it knows the zone is too large for the mask but it tries anyways
because it often works. In that case too much trying is also not good.

-Andi

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Ingo Molnar]

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

> Okay, so how about this then ?
> 
> --- 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-05-28 10:27:41.000000000 +0200
> @@ -397,9 +397,6 @@
>  	if (dev->dma_mask == NULL)
>  		return NULL;
>  
> -	/* Don't invoke OOM killer */
> -	gfp |= __GFP_NORETRY;
> -
>  #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
> @@ -410,7 +407,9 @@
>  #endif
>  
>   again:
> -	page = dma_alloc_pages(dev, gfp, get_order(size));
> +	/* Don't invoke OOM killer or retry in lower 16MB DMA zone */
> +	page = dma_alloc_pages(dev,
> +		(gfp & GFP_DMA) ? gfp | __GFP_NORETRY : gfp, get_order(size));
>  	if (page == NULL)
>  		return NULL;

applied to tip/pci-for-jesse for more testing. Thanks,

	Ingo

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Ingo Molnar]

* 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;
>  
> 

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Jesse Barnes]

On Tuesday, June 10, 2008 3:23 am Ingo Molnar wrote:
> * 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.

Speaking of that branch, how do you want to handle it?  Is it intended for my 
linux-next branch or are some of the fixes important to get upstream now?  
Which branch should I diff/log against to see the changes (last time I looked 
it appeared neither master nor tip were the correct ones...)

Thanks,
Jesse

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Miquel van Smoorenburg]

On Tue, 2008-06-10 at 10:14 -0700, Jesse Barnes wrote:
> On Tuesday, June 10, 2008 3:23 am Ingo Molnar wrote:
> > * 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.
> 
> Speaking of that branch, how do you want to handle it?  Is it intended for my 
> linux-next branch or are some of the fixes important to get upstream now?  
> Which branch should I diff/log against to see the changes (last time I looked 
> it appeared neither master nor tip were the correct ones...)

My opinion is that this particular patch should go into 2.6.26.

Mike.

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Ingo Molnar]

* Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Tuesday, June 10, 2008 3:23 am Ingo Molnar wrote:
> > * 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.
> 
> Speaking of that branch, how do you want to handle it?  Is it intended 
> for my linux-next branch or are some of the fixes important to get 
> upstream now?  Which branch should I diff/log against to see the 
> changes (last time I looked it appeared neither master nor tip were 
> the correct ones...)

that branch is always based in -git so if stuff goes upstream patches 
disappear from it. git-log linus/master..tip/pci-for-jesse should tell 
the currently pending items. Right now it's just two lowprio items:

 Yinghai Lu (2):
      pci: debug extra pci resources range
      pci: debug extra pci bus resources

	Ingo

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Jesse Barnes]

On Thursday, June 26, 2008 4:38 am Ingo Molnar wrote:
> that branch is always based in -git so if stuff goes upstream patches
> disappear from it. git-log linus/master..tip/pci-for-jesse should tell
> the currently pending items. Right now it's just two lowprio items:
>
>  Yinghai Lu (2):
>       pci: debug extra pci resources range
>       pci: debug extra pci bus resources

It looks like these add some new, unconditional debug output?  I guess I 
shouldn't worry about printks so much at this point, given how much 
obsolete/uninteresting info gets dumped these days, but it would be nice if 
this were only dumped if some debug option were set.  Given the variety of 
PCI stuff we might like to dump at various times, maybe it's time we added a 
few new pci=debug=foo options?  Yinghai?

Thanks,
Jesse

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Yinghai Lu]

On Tue, Jul 1, 2008 at 7:39 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Thursday, June 26, 2008 4:38 am Ingo Molnar wrote:
>> that branch is always based in -git so if stuff goes upstream patches
>> disappear from it. git-log linus/master..tip/pci-for-jesse should tell
>> the currently pending items. Right now it's just two lowprio items:
>>
>>  Yinghai Lu (2):
>>       pci: debug extra pci resources range
>>       pci: debug extra pci bus resources
>
> It looks like these add some new, unconditional debug output?  I guess I
> shouldn't worry about printks so much at this point, given how much
> obsolete/uninteresting info gets dumped these days, but it would be nice if
> this were only dumped if some debug option were set.  Given the variety of
> PCI stuff we might like to dump at various times, maybe it's time we added a
> few new pci=debug=foo options?  Yinghai?
>
that is just limited printout. and it is informative..
that is BAR before kernel try to assign new value to it.

YH

Re: [PATCH] 2.6.26-rc: x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY

[Jesse Barnes]

On Tuesday, July 01, 2008 7:46 pm Yinghai Lu wrote:
> On Tue, Jul 1, 2008 at 7:39 PM, Jesse Barnes <jbarnes@virtuousgeek.org> 
wrote:
> > On Thursday, June 26, 2008 4:38 am Ingo Molnar wrote:
> >> that branch is always based in -git so if stuff goes upstream patches
> >> disappear from it. git-log linus/master..tip/pci-for-jesse should tell
> >> the currently pending items. Right now it's just two lowprio items:
> >>
> >>  Yinghai Lu (2):
> >>       pci: debug extra pci resources range
> >>       pci: debug extra pci bus resources
> >
> > It looks like these add some new, unconditional debug output?  I guess I
> > shouldn't worry about printks so much at this point, given how much
> > obsolete/uninteresting info gets dumped these days, but it would be nice
> > if this were only dumped if some debug option were set.  Given the
> > variety of PCI stuff we might like to dump at various times, maybe it's
> > time we added a few new pci=debug=foo options?  Yinghai?
>
> that is just limited printout. and it is informative..
> that is BAR before kernel try to assign new value to it.

Yeah, and it's in keeping with the early (pre-assignment) BAR dumping code you 
added elsewhere.  I'm fine with it as-is, I'll revisit finer grained debug 
options in a future release and fix things up then as needed.

Thanks,
Jesse