Displaying 5 results from an estimated 5 matches for "d42d48c".
Did you mean:
0342d48c
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...t;page = alloc_pages(gfp, order);
>> if (likely(pfrag->page)) {
>> pfrag->offset = 0;
>>
>>
>>
There is another patch needed (looks like good stable fixes):
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 06e72d3..d42d48c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -378,7 +378,7 @@ refill:
gfp_t gfp = gfp_mask;
if (order)
- gfp |= __GFP_COMP | __GFP_NOWARN;
+ gfp |= __GFP_COMP | __GFP_NOWARN |
_...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...t;page = alloc_pages(gfp, order);
>> if (likely(pfrag->page)) {
>> pfrag->offset = 0;
>>
>>
>>
There is another patch needed (looks like good stable fixes):
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 06e72d3..d42d48c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -378,7 +378,7 @@ refill:
gfp_t gfp = gfp_mask;
if (order)
- gfp |= __GFP_COMP | __GFP_NOWARN;
+ gfp |= __GFP_COMP | __GFP_NOWARN |
_...
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...t; if (likely(pfrag->page)) {
> >> pfrag->offset = 0;
> >>
> >>
> >>
>
> There is another patch needed (looks like good stable fixes):
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 06e72d3..d42d48c 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -378,7 +378,7 @@ refill:
> gfp_t gfp = gfp_mask;
>
> if (order)
> - gfp |= __GFP_COMP | __GFP_NOWARN;
> +...
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