Messages in this thread | | | Subject | Re: [patch] net, skbuff: do not prefer skb allocation fails early | From | Eric Dumazet <> | Date | Thu, 3 Jan 2019 02:29:28 -0800 |
| |
On 01/02/2019 01:01 PM, David Rientjes wrote: > Commit dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by > __GFP_RETRY_MAYFAIL with more useful semantic") replaced __GFP_REPEAT in > alloc_skb_with_frags() with __GFP_RETRY_MAYFAIL when the allocation may > directly reclaim. > > The previous behavior would require reclaim up to 1 << order pages for > skb aligned header_len of order > PAGE_ALLOC_COSTLY_ORDER before failing, > otherwise the allocations in alloc_skb() would loop in the page allocator > looking for memory. __GFP_RETRY_MAYFAIL makes both allocations failable > under memory pressure, including for the HEAD allocation. > > This can cause, among many other things, write() to fail with ENOTCONN > during RPC when under memory pressure. > > These allocations should succeed as they did previous to dcda9b04713c > even if it requires calling the oom killer and additional looping in the > page allocator to find memory. There is no way to specify the previous > behavior of __GFP_REPEAT, but it's unlikely to be necessary since the > previous behavior only guaranteed that 1 << order pages would be reclaimed > before failing for order > PAGE_ALLOC_COSTLY_ORDER. That reclaim is not > guaranteed to be contiguous memory, so repeating for such large orders is > usually not beneficial. > > Removing the setting of __GFP_RETRY_MAYFAIL to restore the previous > behavior, specifically not allowing alloc_skb() to fail for small orders > and oom kill if necessary rather than allowing RPCs to fail. > > Fixes: dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by > __GFP_RETRY_MAYFAIL with more useful semantic") > Signed-off-by: David Rientjes <rientjes@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks David.
| |