Displaying 3 results from an estimated 3 matches for "direct_reclaim".
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...FP_NORETRY;
> pfrag->page = alloc_pages(gfp, order);
> if (likely(pfrag->page)) {
> pfrag->offset = 0;
>
>
>
Yes this seems like it will make the situation better, but one send()
may still cause a direct_compact and direct_reclaim() cycle to happen,
followed immediately by another direct_compact() if direct_reclaim()
didn't free an order-3. Now have all cpu's doing a send(), you can
still get heavy spinlock contention in the routines described above.
The major change I see here is that allocations > order-0 used t...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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