Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-18 Thread Michal Hocko
On Tue 18-07-17 06:42:31, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > > Since the whole memory reclaim path has never been designed to handle the > > > scheduling priority inversions, those locations which are assuming that > > > execution of

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-18 Thread Michal Hocko
On Tue 18-07-17 06:42:31, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > > Since the whole memory reclaim path has never been designed to handle the > > > scheduling priority inversions, those locations which are assuming that > > > execution of

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Tetsuo Handa
Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Tetsuo Handa
Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > Since the whole memory reclaim path has never been designed to handle the > scheduling priority inversions, those locations which are assuming that > execution of some code path shall eventually complete without using > synchronization mechanisms can

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > Since the whole memory reclaim path has never been designed to handle the > scheduling priority inversions, those locations which are assuming that > execution of some code path shall eventually complete without using > synchronization mechanisms can

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Mon 17-07-17 22:50:47, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > > Since the whole memory reclaim path has never been designed to handle the > > > scheduling priority inversions, those locations which are assuming that > > > execution of

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Mon 17-07-17 22:50:47, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > > Since the whole memory reclaim path has never been designed to handle the > > > scheduling priority inversions, those locations which are assuming that > > > execution of

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Tetsuo Handa
Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Tetsuo Handa
Michal Hocko wrote: > On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > > Since the whole memory reclaim path has never been designed to handle the > > scheduling priority inversions, those locations which are assuming that > > execution of some code path shall eventually complete without using > >

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > Since the whole memory reclaim path has never been designed to handle the > scheduling priority inversions, those locations which are assuming that > execution of some code path shall eventually complete without using > synchronization mechanisms can

Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-17 Thread Michal Hocko
On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > Since the whole memory reclaim path has never been designed to handle the > scheduling priority inversions, those locations which are assuming that > execution of some code path shall eventually complete without using > synchronization mechanisms can

[PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-16 Thread Tetsuo Handa
Since the whole memory reclaim path has never been designed to handle the scheduling priority inversions, those locations which are assuming that execution of some code path shall eventually complete without using synchronization mechanisms can get stuck (livelock) due to scheduling priority

[PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.

2017-07-16 Thread Tetsuo Handa
Since the whole memory reclaim path has never been designed to handle the scheduling priority inversions, those locations which are assuming that execution of some code path shall eventually complete without using synchronization mechanisms can get stuck (livelock) due to scheduling priority