search for: page_alloc_costly_ord

...6,7 +8366,8 @@ struct net_device *alloc_netdev_mqs(int > > /* ensure 32-byte alignment of whole construct */ > > alloc_size += NETDEV_ALIGN - 1; > > > > - p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > > + WARN_ON(alloc_size > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER); > > + p = kzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > > if (!p) > > return NULL; > > > > > > Since when a net_device needs to be in DMA zone ??? > > I would rather fix virtio_net, this looks very suspect to me. > > Each vir...

...6,7 +8366,8 @@ struct net_device *alloc_netdev_mqs(int > > /* ensure 32-byte alignment of whole construct */ > > alloc_size += NETDEV_ALIGN - 1; > > > > - p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > > + WARN_ON(alloc_size > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER); > > + p = kzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); > > if (!p) > > return NULL; > > > > > > Since when a net_device needs to be in DMA zone ??? > > I would rather fix virtio_net, this looks very suspect to me. > > Each vir...

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 __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 int sz, struct page_frag *pfrag, gfp_t prio)...

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 __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 int sz, struct page_frag *pfrag, gfp_t prio)...

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 allocations. On systems that have highly fragmented main memory with pressure, skb_page_frag_refill()

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 allocations. On systems that have highly fragmented main memory with pressure, skb_page_frag_refill()

...struct net_device *alloc_netdev_mqs(int >>> /* ensure 32-byte alignment of whole construct */ >>> alloc_size += NETDEV_ALIGN - 1; >>> >>> - p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); >>> + WARN_ON(alloc_size > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER); >>> + p = kzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL); >>> if (!p) >>> return NULL; >>> >>> >> >> Since when a net_device needs to be in DMA zone ??? >> >> I would rather fix virtio_net, this looks very suspec...

...ugh > __alloc_pages_direct_compact() and triggering the bad events above. It > will take me several days to try this experiment. 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

...t; 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 reason PAGE_ALLOC_COSTLY_ORDER exists and is 3 Sorry 2GB cache out of 8GB phys, ~1GB gets reclaimed. Regardless the reclaimation of cache is minor compared to the compaction event that precedes it, I haven't spotted something addressing that yet - isolate_migratepages_range ()/compact_checklock_irqsave(). If even more of...