Displaying 20 results from an estimated 127 matches for "skb_page_frag_refil".
Did you mean:
skb_page_frag_refill
2013 Dec 23
1
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Mon, 2013-12-23 at 14:53 +0200, Michael S. Tsirkin wrote:
> 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 allocator will fall back to
> > successively smaller page...
2013 Dec 23
1
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Mon, 2013-12-23 at 14:53 +0200, Michael S. Tsirkin wrote:
> 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 allocator will fall back to
> > successively smaller page...
2013 Nov 12
0
[PATCH net-next 2/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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 order-0 page allocs)....
2013 Dec 23
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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 back to
> successively smaller page allocs (down to ord...
2013 Dec 23
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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 allocator will fall back to
> successively smaller page allocs (down to ord...
2014 Jan 08
0
[PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Mon, Jan 06, 2014 at 09:25:52PM -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 allocator will fall back to
> successively smaller page allocs (down to ord...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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() causes problems. mm enters significant
compaction cycles on all cpu's which in itself is bad (add
considerable spinlock contention in isolate_migratepages_range() for
several seconds in kernel at 100% cpu), however even without this
happening basically we have large memory reclaimation when...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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() causes problems. mm enters significant
compaction cycles on all cpu's which in itself is bad (add
considerable spinlock contention in isolate_migratepages_range() for
several seconds in kernel at 100% cpu), however even without this
happening basically we have large memory reclaimation when...
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...ay 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() causes problems. mm enters significant
> compaction cycles on all cpu's which in itself is bad (add
> considerable spinlock contention in isolate_migratepages_range() for
> several seconds in kernel at 100% cpu), however even without this
> happening basically we have large memor...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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)
gfp_t gfp = prio;
if (order)
- gfp |= __GFP_COMP | __GFP_NOWARN;
+ gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
pfrag->page = alloc_pages(gfp, order);
if (likely(pfrag->page)) {
pfrag->offset = 0;
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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)
gfp_t gfp = prio;
if (order)
- gfp |= __GFP_COMP | __GFP_NOWARN;
+ gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
pfrag->page = alloc_pages(gfp, order);
if (likely(pfrag->page)) {
pfrag->offset = 0;
2013 Dec 17
15
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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 order-0 page allocs)....
2013 Dec 17
15
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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 order-0 page allocs)....
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...Michael doesn't make this behavior worse.
>
> 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)
> gfp_t gfp = prio;
>
> if (order)
> - gfp |= __GFP_COMP | __GFP_NOWARN;
> + gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
> pfrag...
2014 Jan 03
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...s 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)
> >> gfp_t gfp = prio;
> >>
> >> if (order)
> >> - gfp |= __GFP_COMP | __GFP_NOWARN;
> >> + gfp |= __GFP_COMP | __GFP_NOWAR...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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 int sz, struct page_frag *pfrag, gfp_t prio)
>> gfp_t gfp = prio;
>>
>> if (order)
>> - gfp |= __GFP_COMP | __GFP_NOWARN;
>> + gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
>&g...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...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 int sz, struct page_frag *pfrag, gfp_t prio)
>> gfp_t gfp = prio;
>>
>> if (order)
>> - gfp |= __GFP_COMP | __GFP_NOWARN;
>> + gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
>&g...
2013 Dec 19
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
Can I get some reviews of this series from virtio folks?
Thanks.
2013 Dec 24
0
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
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.
2014 Jan 08
2
[PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill
On Wed, 2014-01-08 at 20:08 +0200, Michael S. Tsirkin wrote:
> Eric said we also need a patch to add __GFP_NORETRY, right?
> Probably before this one in series.
Nope, this __GFP_NORETRY has nothing to do with this.
I am not yet convinced we want it.
This needs mm guys advice, as its a tradeoff for mm layer more than
networking...