Currently because of how mm behaves (3.10.y) the code even before the
patch is a problem. I believe what may fix it is if instead of just
removing the conditional on __GFP_WAIT, the initial order 0
allocation should be made GFP_ATOMIC, then fallback to the original
gfp mask for the order-0
On Thu, Jan 2, 2014 at 8:26 PM, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote:
My suggestion is to use a recent kernel, and/or eventually backport the
mm fixes if any.
order-3 allocations should not reclaim 2GB out of 8GB.
There is a
On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote:
Hmm... it looks like I missed __GFP_NORETRY
diff --git a/net/core/sock.c b/net/core/sock.c
index 5393b4b719d7..5f42a4d70cb2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1872,7 +1872,7 @@ bool skb_page_frag_refill(unsigned
On Fri, Jan 3, 2014 at 5:54 PM, Eric Dumazet eric.duma...@gmail.com wrote:
This is in GFP_ATOMIC cases, I dont think it can ever start compaction.
I think that's right I probably finally got it back to normal behavior
with order-0 allocations.
It seems that you shoot the messenger : If
On Fri, 2014-01-03 at 17:47 -0500, Debabrata Banerjee wrote:
On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote:
Hmm... it looks like I missed __GFP_NORETRY
diff --git a/net/core/sock.c b/net/core/sock.c
index 5393b4b719d7..5f42a4d70cb2 100644
--- a/net/core/sock.c
+++
On Thu, 2014-01-02 at 19:42 -0500, Debabrata Banerjee wrote:
Currently because of how mm behaves (3.10.y) the code even before the
patch is a problem. I believe what may fix it is if instead of just
removing the conditional on __GFP_WAIT, the initial order 0
allocation should be made
On Thu, 2014-01-02 at 16:56 -0800, Eric Dumazet wrote:
My suggestion is to use a recent kernel, and/or eventually backport the
mm fixes if any.
order-3 allocations should not reclaim 2GB out of 8GB.
There is a reason PAGE_ALLOC_COSTLY_ORDER exists and is 3
Hmm... it looks like I missed
There is still feedback and/or minor adjustments being asked for wrt.
this series. These changes have been sitting for more than a week
which is a bit rediculous.
Please resubmit these changes once everything is resolved to
everyone's satisfaction, thanks.
On Mon, Dec 16, 2013 at 04:16:27PM -0800, Michael Dalton wrote:
skb_page_frag_refill currently permits only order-0 page allocs
unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
higher-order page allocations whether or not GFP_WAIT is used. If
memory cannot be allocated, the
On Thu, Dec 19, 2013 at 02:58:15PM -0500, David Miller wrote:
Can I get some reviews of this series from virtio folks?
Thanks.
I think it's a good idea, certainly the best we can do
short term.
Would like a couple of comments addressed before it's applied.
Longer term one approach to
On Mon, 2013-12-23 at 15:52 +0800, Jason Wang wrote:
On 12/17/2013 08:16 AM, Michael Dalton wrote:
skb_page_frag_refill currently permits only order-0 page allocs
unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
higher-order page allocations whether or not GFP_WAIT is used.
On 12/17/2013 08:16 AM, Michael Dalton wrote:
skb_page_frag_refill currently permits only order-0 page allocs
unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
higher-order page allocations whether or not GFP_WAIT is used. If
memory cannot be allocated, the allocator will fall
Can I get some reviews of this series from virtio folks?
Thanks.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
skb_page_frag_refill currently permits only order-0 page allocs
unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
higher-order page allocations whether or not GFP_WAIT is used. If
memory cannot be allocated, the allocator will fall back to
successively smaller page allocs (down to
14 matches
Mail list logo
