Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sat 17-12-16 20:17:07, Tetsuo Handa wrote: [...] > I feel that allowing access to memory reserves based on __GFP_NOFAIL might not > make sense. My understanding is that actual I/O operation triggered by I/O > requests by filesystem code are processed by other threads. Even if we grant > access

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sat 17-12-16 20:17:07, Tetsuo Handa wrote: [...] > I feel that allowing access to memory reserves based on __GFP_NOFAIL might not > make sense. My understanding is that actual I/O operation triggered by I/O > requests by filesystem code are processed by other threads. Even if we grant > access

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Fri 16-12-16 12:31:51, Johannes Weiner wrote: >>> @@ -3737,6 +3752,16 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int >>> order, >>> */ >>> WARN_ON_ONCE(order > PAGE_ALLOC_COSTLY_ORDER); >>> >>> + /* >>> +* Help

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Fri 16-12-16 12:31:51, Johannes Weiner wrote: >>> @@ -3737,6 +3752,16 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int >>> order, >>> */ >>> WARN_ON_ONCE(order > PAGE_ALLOC_COSTLY_ORDER); >>> >>> + /* >>> +* Help

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Fri 16-12-16 12:31:51, Johannes Weiner wrote: > On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote: > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) > > * make sure exclude 0 mask - all other users should have at least > > * ___GFP_DIRECT_RECLAIM to get

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Fri 16-12-16 12:31:51, Johannes Weiner wrote: > On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote: > > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) > > * make sure exclude 0 mask - all other users should have at least > > * ___GFP_DIRECT_RECLAIM to get

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote: > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) >* make sure exclude 0 mask - all other users should have at least >* ___GFP_DIRECT_RECLAIM to get here. >*/ > - if (oc->gfp_mask &&

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Fri, Dec 16, 2016 at 04:58:08PM +0100, Michal Hocko wrote: > @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc) >* make sure exclude 0 mask - all other users should have at least >* ___GFP_DIRECT_RECLAIM to get here. >*/ > - if (oc->gfp_mask &&

[PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and

[PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and it can be quite

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 12-12-16 09:48:37, Michal Hocko wrote: > On Sun 11-12-16 20:23:47, Tetsuo Handa wrote: [...] > > I believe that __GFP_NOFAIL should not imply invocation of the OOM killer. > > Therefore, I want to change __GFP_NOFAIL not to invoke the OOM killer. > > But since currently the OOM killer

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 12-12-16 09:48:37, Michal Hocko wrote: > On Sun 11-12-16 20:23:47, Tetsuo Handa wrote: [...] > > I believe that __GFP_NOFAIL should not imply invocation of the OOM killer. > > Therefore, I want to change __GFP_NOFAIL not to invoke the OOM killer. > > But since currently the OOM killer

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sun 11-12-16 22:53:55, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > > > If we could agree > > > > with calling __alloc_pages_nowmark() before out_of_memory() if > > > > __GFP_NOFAIL > > > > is given, we can avoid

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sun 11-12-16 22:53:55, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Michal Hocko wrote: > > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > > > If we could agree > > > > with calling __alloc_pages_nowmark() before out_of_memory() if > > > > __GFP_NOFAIL > > > > is given, we can avoid

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sun 11-12-16 20:23:47, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: [...] > > > > If you believe that my argumentation is incorrect then you are free to > > > > nak the patch with your reasoning. But please stop this nit picking on > > > > nonsense

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Sun 11-12-16 20:23:47, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: [...] > > > > If you believe that my argumentation is incorrect then you are free to > > > > nak the patch with your reasoning. But please stop this nit picking on > > > > nonsense

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > > If we could agree > > > with calling __alloc_pages_nowmark() before out_of_memory() if > > > __GFP_NOFAIL > > > is given, we can avoid locking up while minimizing possibility of invoking > > > the

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Tetsuo Handa wrote: > Michal Hocko wrote: > > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > > If we could agree > > > with calling __alloc_pages_nowmark() before out_of_memory() if > > > __GFP_NOFAIL > > > is given, we can avoid locking up while minimizing possibility of invoking > > > the

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > If we could agree > > with calling __alloc_pages_nowmark() before out_of_memory() if __GFP_NOFAIL > > is given, we can avoid locking up while minimizing possibility of invoking > > the OOM killer... > > I do not understand. We

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > > If we could agree > > with calling __alloc_pages_nowmark() before out_of_memory() if __GFP_NOFAIL > > is given, we can avoid locking up while minimizing possibility of invoking > > the OOM killer... > > I do not understand. We

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > > > You are trying to increase possible locations of lockups by changing > > > default behavior of __GFP_NOFAIL. > > > > I disagree. I have tried to explain that it is much more

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Thu 08-12-16 21:53:44, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > > > You are trying to increase possible locations of lockups by changing > > > default behavior of __GFP_NOFAIL. > > > > I disagree. I have tried to explain that it is much more

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > > You are trying to increase possible locations of lockups by changing > > default behavior of __GFP_NOFAIL. > > I disagree. I have tried to explain that it is much more important to > have fewer silent side effects than

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > > You are trying to increase possible locations of lockups by changing > > default behavior of __GFP_NOFAIL. > > I disagree. I have tried to explain that it is much more important to > have fewer silent side effects than

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tue 06-12-16 12:03:02, Vlastimil Babka wrote: > On 12/06/2016 11:38 AM, Tetsuo Handa wrote: > >> > >> So we are somewhere in the middle between pre-mature and pointless > >> system disruption (GFP_NOFS with a lots of metadata or lowmem request) > >> where the OOM killer even might not help and

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tue 06-12-16 12:03:02, Vlastimil Babka wrote: > On 12/06/2016 11:38 AM, Tetsuo Handa wrote: > >> > >> So we are somewhere in the middle between pre-mature and pointless > >> system disruption (GFP_NOFS with a lots of metadata or lowmem request) > >> where the OOM killer even might not help and

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > > > the allocation request. This includes lowmem requests, costly high >

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Tue 06-12-16 19:38:38, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > > > the allocation request. This includes lowmem requests, costly high >

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On 12/06/2016 11:38 AM, Tetsuo Handa wrote: >> >> So we are somewhere in the middle between pre-mature and pointless >> system disruption (GFP_NOFS with a lots of metadata or lowmem request) >> where the OOM killer even might not help and potential lockup which is >> inevitable with the current

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On 12/06/2016 11:38 AM, Tetsuo Handa wrote: >> >> So we are somewhere in the middle between pre-mature and pointless >> system disruption (GFP_NOFS with a lots of metadata or lowmem request) >> where the OOM killer even might not help and potential lockup which is >> inevitable with the current

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > > the allocation request. This includes lowmem requests, costly high > > > order requests and others. For a long time

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > > Michal Hocko wrote: > > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > > the allocation request. This includes lowmem requests, costly high > > > order requests and others. For a long time

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 05-12-16 15:10:09, Michal Hocko wrote: [...] > So we are somewhere in the middle between pre-mature and pointless > system disruption (GFP_NOFS with a lots of metadata or lowmem request) > where the OOM killer even might not help and potential lockup which is > inevitable with the current

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 05-12-16 15:10:09, Michal Hocko wrote: [...] > So we are somewhere in the middle between pre-mature and pointless > system disruption (GFP_NOFS with a lots of metadata or lowmem request) > where the OOM killer even might not help and potential lockup which is > inevitable with the current

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > Michal Hocko wrote: > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > the allocation request. This includes lowmem requests, costly high > > order requests and others. For a long time __GFP_NOFAIL acted as an > > override

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On Mon 05-12-16 22:45:19, Tetsuo Handa wrote: > Michal Hocko wrote: > > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > > the allocation request. This includes lowmem requests, costly high > > order requests and others. For a long time __GFP_NOFAIL acted as an > > override

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > the allocation request. This includes lowmem requests, costly high > order requests and others. For a long time __GFP_NOFAIL acted as an > override for all those rules. This is not documented and it can be

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

Michal Hocko wrote: > __alloc_pages_may_oom makes sure to skip the OOM killer depending on > the allocation request. This includes lowmem requests, costly high > order requests and others. For a long time __GFP_NOFAIL acted as an > override for all those rules. This is not documented and it can be

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On 12/01/2016 04:25 PM, Michal Hocko wrote: From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override

Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

On 12/01/2016 04:25 PM, Michal Hocko wrote: From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those

[PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and

[PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically

From: Michal Hocko __alloc_pages_may_oom makes sure to skip the OOM killer depending on the allocation request. This includes lowmem requests, costly high order requests and others. For a long time __GFP_NOFAIL acted as an override for all those rules. This is not documented and it can be quite