From: Amitkumar Karwar
> Sent: 05 April 2016 06:48
...
> Our one time allocated 64k buffer read from firmware contains multiple data
> chunks. We have a feature
> called single port aggregation in which firmware attaches an aggregated
> buffer to single port. So
> sometimes a single data chunk ca
glas
> Anderson
> Subject: Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call
>
> On Tue, 2016-03-29 at 17:27 +0800, Wei-Ning Huang wrote:
> > Adding some chromium devs to the thread.
> >
> > In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
On Tue, 2016-03-29 at 17:27 +0800, Wei-Ning Huang wrote:
> Adding some chromium devs to the thread.
>
> In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
>
> The default mm retry allocation when 'order <=
> PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT.
> PAGE_ALLOC_COST
> From: Wei-Ning Huang [mailto:wnhu...@google.com]
> Sent: Tuesday, March 29, 2016 2:57 PM
> To: Kalle Valo
> Cc: Linux Wireless; LKML; Amitkumar Karwar; Nishant Sarmukadam; Sameer
> Nanda; netdev@vger.kernel.org; Sonny Rao; Douglas Anderson
> Subject: Re: [PATCH] mwifiex: add _
Adding some chromium devs to the thread.
In, http://lxr.free-electrons.com/source/mm/page_alloc.c#L3152
The default mm retry allocation when 'order <=
PAGE_ALLOC_COSTLY_ORDER' of gfp_mask contains __GFP_REPEAT.
PAGE_ALLOC_COSTLY_ORDER is defined to be 3. On systems with page size
= 4K, this means
Wei-Ning Huang writes:
> "single skb allocation failure" happens when system is under heavy
> memory pressure. Add __GFP_REPEAT to skb allocation call so kernel
> attempts to reclaim pages and retry the allocation.
>
> Signed-off-by: Wei-Ning Huang
Is this really a proper way to fix the issue?
On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote:
> "single skb allocation failure" happens when system is under heavy
> memory pressure. Add __GFP_REPEAT to skb allocation call so kernel
> attempts to reclaim pages and retry the allocation.
Oh, that's interesting, we're back to thi
