search for: __gfp_noretry

Displaying 20 results from an estimated 151 matches for "__gfp_noretry".

2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...r() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation...
2017 Sep 11
6
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...r() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory allocation. Such __GFP_DIRECT_RECLAIM | !__GFP_NORETRY allocation...
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...
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...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...-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) gfp_t gfp = prio; if (order) - gfp |= __GFP_COMP | __...
2014 Jan 03
2
[PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag_refill
...-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) gfp_t gfp = prio; if (order) - gfp |= __GFP_COMP | __...
2017 Aug 03
6
[PATCH RESEND] mm: don't zero ballooned pages
...action.c index 9075aa5..b06d9fe 100644 --- a/mm/balloon_compaction.c +++ b/mm/balloon_compaction.c @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info) { unsigned long flags; struct page *page = alloc_page(balloon_mapping_gfp_mask() | - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO); + __GFP_NOMEMALLOC | __GFP_NORETRY); if (!page) return NULL; -- 2.7.4
2017 Aug 03
6
[PATCH RESEND] mm: don't zero ballooned pages
...action.c index 9075aa5..b06d9fe 100644 --- a/mm/balloon_compaction.c +++ b/mm/balloon_compaction.c @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info) { unsigned long flags; struct page *page = alloc_page(balloon_mapping_gfp_mask() | - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO); + __GFP_NOMEMALLOC | __GFP_NORETRY); if (!page) return NULL; -- 2.7.4
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 21:18 +0200, Michael S. Tsirkin wrote: > On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote: > > 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...
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 21:18 +0200, Michael S. Tsirkin wrote: > On Wed, Jan 08, 2014 at 10:26:03AM -0800, Eric Dumazet wrote: > > 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...
2017 Oct 02
0
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...gt; > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > > > > depend on somebody else's __GFP...
2017 Oct 02
0
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...T_RECLAIM memory allocation. > > > > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory >...
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: >> >> 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...
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: >> >> 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...
2017 Sep 29
0
mm, virtio: possible OOM lockup at virtballoon_oom_notify()
...om virtballoon_oom_notify() might depend on > __GFP_DIRECT_RECLAIM memory allocation. > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > serialize against fill_balloon(). But in fill_balloon(), > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > depend on somebody else's __GFP_DIRECT_RECLAIM | !__GFP_NORETRY memory > allocation. Such __GFP_DIRECT_RECLAIM | !__GF...
2017 Jul 31
2
[PATCH] mm: don't zero ballooned pages
...action.c index 9075aa5..b06d9fe 100644 --- a/mm/balloon_compaction.c +++ b/mm/balloon_compaction.c @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info) { unsigned long flags; struct page *page = alloc_page(balloon_mapping_gfp_mask() | - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO); + __GFP_NOMEMALLOC | __GFP_NORETRY); if (!page) return NULL; -- 2.7.4
2017 Jul 31
2
[PATCH] mm: don't zero ballooned pages
...action.c index 9075aa5..b06d9fe 100644 --- a/mm/balloon_compaction.c +++ b/mm/balloon_compaction.c @@ -24,7 +24,7 @@ struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info) { unsigned long flags; struct page *page = alloc_page(balloon_mapping_gfp_mask() | - __GFP_NOMEMALLOC | __GFP_NORETRY | __GFP_ZERO); + __GFP_NOMEMALLOC | __GFP_NORETRY); if (!page) return NULL; -- 2.7.4
2017 Oct 02
2
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > > > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > > > > > depend on somebody e...
2017 Oct 02
2
[RFC] [PATCH] mm,oom: Offload OOM notify callback to a kernel thread.
...> > > > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > > > > > > serialize against fill_balloon(). But in fill_balloon(), > > > > > > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > > > > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies > > > > > > > > __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might > > > > > > > > depend on somebody e...
2017 Nov 08
2
[PATCH v3] virtio_balloon: fix deadlock on OOM
...nqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY is specified, this allocation attempt might indirectly depend on somebody else's __GFP_DIRECT_RECLAIM memory allocation. And such indirect __GFP...