Re: iwl3945: order 5 allocation during ifconfig up; vm problem?

On Wed, Oct 03, 2012 at 11:07:13AM -0700, David Rientjes wrote:

On Wed, 3 Oct 2012, Stanislaw Gruszka wrote:

quoted

So, can this problem be solved like on below patch, or I should rather
split firmware loading into chunks similar like was already iwlwifi did?

Hmm, I looked at iwl3945 code and looks loading firmware in chunks is
nothing that can be easily done. 3945 bootstrap code expect that runtime
ucode will be placed in physically continue memory, and there are no
separate instructions for copy and for execute, just one to perform both
those actions. Maybe loading firmware in chunks can be done using
undocumented features of the device, but I'm eager to do this.

quoted

diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index 5f50177..1b58222 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h

@@ -2247,7 +2247,7 @@ il_alloc_fw_desc(struct pci_dev *pci_dev, struct fw_desc *desc)
 
 	desc->v_addr =
 	    dma_alloc_coherent(&pci_dev->dev, desc->len, &desc->p_addr,
-			       GFP_KERNEL);
+			       GFP_KERNEL | __GFP_REPEAT);
 	return (desc->v_addr != NULL) ? 0 : -ENOMEM;
 }
 

I think this will certainly make memory compaction more aggressive by 
avoiding the logic to defer calling compaction in the page allocator, but 
because we lack lumpy reclaim this still has a higher probability of 
failing than it had in the past because it will fail if 128KB of memory is 
reclaimed that may not happen to be contiguous for an order-5 allocation 
to succeed.

I understand that complex systems like virtual memory manager require
various design compromises. In this case decision was to make memory
allocator to perform faster in cost of possible allocation failures.
I'm not quite sure if that was good decision, but I think VM developers
know best what is good for VM.

However, maybe this allocation issue initially reported here, was
caused by some bug, which is possibly now fixed i.e. memory leak on
some driver or subsystem. 

Pavel, do you still can reproduce this problem on released 3.6 ? 

Thanks
Stanislaw