On Tue 24-04-18 17:08:15, Michal Hocko wrote:
> On Tue 24-04-18 14:07:52, David Rientjes wrote:
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > > > > My patch has passed intensive testing on both x86 and powerpc, so
> > > > > > I'll ask
> > > > > > that it's pushed for 4.17-rc3. Many tha
On Tue 24-04-18 14:07:52, David Rientjes wrote:
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > > > > My patch has passed intensive testing on both x86 and powerpc, so
> > > > > I'll ask
> > > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the
> > > > > suggestion
> > > > > on
On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > My patch has passed intensive testing on both x86 and powerpc, so I'll
> > > > ask
> > > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the
> > > > suggestion
> > > > on calling __oom_reap_task_mm() from exit_mmap().
> > >
> > > Ye
On Tue 24-04-18 13:22:45, David Rientjes wrote:
[...]
> > > My patch has passed intensive testing on both x86 and powerpc, so I'll
> > > ask
> > > that it's pushed for 4.17-rc3. Many thanks to Tetsuo for the suggestion
> > > on calling __oom_reap_task_mm() from exit_mmap().
> >
> > Yeah, but y
On Tue, 24 Apr 2018, Michal Hocko wrote:
> > I wanted to remove all per task checks because they are now irrelevant:
> > this would be the first dependency that exit_mmap() has on any
> > task_struct, which isn't intuitive -- we simply want to exit the mmap.
> > There's no requirement that cur
On Tue 24-04-18 13:01:03, David Rientjes wrote:
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > Is there any reason why we cannot simply call __oom_reap_task_mm as we
> > have it now? mmap_sem for read shouldn't fail here because this is the
> > last reference of the mm and we are past the ksm an
On Tue, 24 Apr 2018, Michal Hocko wrote:
> Is there any reason why we cannot simply call __oom_reap_task_mm as we
> have it now? mmap_sem for read shouldn't fail here because this is the
> last reference of the mm and we are past the ksm and khugepaged
> synchronizations. So unless my jed laged br
On Mon 23-04-18 19:31:05, David Rientjes wrote:
[...]
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3015,6 +3015,27 @@ void exit_mmap(struct mm_struct *mm)
> /* mm's last user has gone, and its about to be pulled down */
> mmu_notifier_release(mm);
>
>
On Tue, 24 Apr 2018, Tetsuo Handa wrote:
> > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before
> > > exit_mmap() holds mmap_sem for write. Then, at least memory which could
> > > have been reclaimed if exit_mmap() did not hold mmap_sem for write will
> > > be guaranteed to
> On Sun, 22 Apr 2018, Tetsuo Handa wrote:
>
> > > I'm wondering why you do not see oom killing of many processes if the
> > > victim is a very large process that takes a long time to free memory in
> > > exit_mmap() as I do because the oom reaper gives up trying to acquire
> > > mm->mmap_sem a
On Sun, 22 Apr 2018, Tetsuo Handa wrote:
> > I'm wondering why you do not see oom killing of many processes if the
> > victim is a very large process that takes a long time to free memory in
> > exit_mmap() as I do because the oom reaper gives up trying to acquire
> > mm->mmap_sem and just sets
On Sun 22-04-18 12:48:13, Tetsuo Handa wrote:
> David Rientjes wrote:
> > How have you tested this?
> >
> > I'm wondering why you do not see oom killing of many processes if the
> > victim is a very large process that takes a long time to free memory in
> > exit_mmap() as I do because the oom re
David Rientjes wrote:
> How have you tested this?
>
> I'm wondering why you do not see oom killing of many processes if the
> victim is a very large process that takes a long time to free memory in
> exit_mmap() as I do because the oom reaper gives up trying to acquire
> mm->mmap_sem and just s
13 matches
Mail list logo
