On Wed 13-06-18 22:20:49, Tetsuo Handa wrote:
> On 2018/06/05 17:57, Michal Hocko wrote:
> >> For this reason, we see testing harnesses often oom killed immediately
> >> after running a unittest that stresses reclaim or compaction by inducing a
> >> system-wide oom condition. The harness spawns
On Wed 13-06-18 22:20:49, Tetsuo Handa wrote:
> On 2018/06/05 17:57, Michal Hocko wrote:
> >> For this reason, we see testing harnesses often oom killed immediately
> >> after running a unittest that stresses reclaim or compaction by inducing a
> >> system-wide oom condition. The harness spawns
On 2018/06/05 17:57, Michal Hocko wrote:
>> For this reason, we see testing harnesses often oom killed immediately
>> after running a unittest that stresses reclaim or compaction by inducing a
>> system-wide oom condition. The harness spawns the unittest which spawns
>> an antagonist memory
On 2018/06/05 17:57, Michal Hocko wrote:
>> For this reason, we see testing harnesses often oom killed immediately
>> after running a unittest that stresses reclaim or compaction by inducing a
>> system-wide oom condition. The harness spawns the unittest which spawns
>> an antagonist memory
On Mon 04-06-18 21:25:39, David Rientjes wrote:
> On Fri, 1 Jun 2018, Michal Hocko wrote:
>
> > > We've discussed the mm
> > > having a single blockable mmu notifier. Regardless of how we arrive at
> > > the point where the oom reaper can't free memory, which could be any of
> > > those three
On Mon 04-06-18 21:25:39, David Rientjes wrote:
> On Fri, 1 Jun 2018, Michal Hocko wrote:
>
> > > We've discussed the mm
> > > having a single blockable mmu notifier. Regardless of how we arrive at
> > > the point where the oom reaper can't free memory, which could be any of
> > > those three
On Fri, 1 Jun 2018, Michal Hocko wrote:
> > We've discussed the mm
> > having a single blockable mmu notifier. Regardless of how we arrive at
> > the point where the oom reaper can't free memory, which could be any of
> > those three cases, if (1) the original victim is sufficiently large
On Fri, 1 Jun 2018, Michal Hocko wrote:
> > We've discussed the mm
> > having a single blockable mmu notifier. Regardless of how we arrive at
> > the point where the oom reaper can't free memory, which could be any of
> > those three cases, if (1) the original victim is sufficiently large
On Thu 31-05-18 14:16:34, David Rientjes wrote:
> On Thu, 31 May 2018, Michal Hocko wrote:
>
> > > It's not a random timeout, it's sufficiently long such that we don't oom
> > > kill several processes needlessly in the very rare case where oom
> > > livelock
> > > would actually prevent the
On Thu 31-05-18 14:16:34, David Rientjes wrote:
> On Thu, 31 May 2018, Michal Hocko wrote:
>
> > > It's not a random timeout, it's sufficiently long such that we don't oom
> > > kill several processes needlessly in the very rare case where oom
> > > livelock
> > > would actually prevent the
On Thu, 31 May 2018, Michal Hocko wrote:
> > It's not a random timeout, it's sufficiently long such that we don't oom
> > kill several processes needlessly in the very rare case where oom livelock
> > would actually prevent the original victim from exiting. The oom reaper
> > processing an
On Thu, 31 May 2018, Michal Hocko wrote:
> > It's not a random timeout, it's sufficiently long such that we don't oom
> > kill several processes needlessly in the very rare case where oom livelock
> > would actually prevent the original victim from exiting. The oom reaper
> > processing an
On Wed 30-05-18 14:06:51, David Rientjes wrote:
> On Mon, 28 May 2018, Michal Hocko wrote:
>
> > > That's not sufficient since the oom reaper is also not able to oom reap
> > > if
> > > the mm has blockable mmu notifiers or all memory is shared filebacked
> > > memory, so it immediately sets
On Wed 30-05-18 14:06:51, David Rientjes wrote:
> On Mon, 28 May 2018, Michal Hocko wrote:
>
> > > That's not sufficient since the oom reaper is also not able to oom reap
> > > if
> > > the mm has blockable mmu notifiers or all memory is shared filebacked
> > > memory, so it immediately sets
On Mon, 28 May 2018, Michal Hocko wrote:
> > That's not sufficient since the oom reaper is also not able to oom reap if
> > the mm has blockable mmu notifiers or all memory is shared filebacked
> > memory, so it immediately sets MMF_OOM_SKIP and additional processes are
> > oom killed.
>
>
On Mon, 28 May 2018, Michal Hocko wrote:
> > That's not sufficient since the oom reaper is also not able to oom reap if
> > the mm has blockable mmu notifiers or all memory is shared filebacked
> > memory, so it immediately sets MMF_OOM_SKIP and additional processes are
> > oom killed.
>
>
On Fri 25-05-18 12:36:08, David Rientjes wrote:
> On Fri, 25 May 2018, Michal Hocko wrote:
>
> > > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > > it cannot reap an mm. This can happen for a variety of reasons,
> > > including:
> > >
> > > - the inability to
On Fri 25-05-18 12:36:08, David Rientjes wrote:
> On Fri, 25 May 2018, Michal Hocko wrote:
>
> > > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > > it cannot reap an mm. This can happen for a variety of reasons,
> > > including:
> > >
> > > - the inability to
On Fri, 25 May 2018, Tetsuo Handa wrote:
> > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > it cannot reap an mm. This can happen for a variety of reasons,
> > including:
> >
> > - the inability to grab mm->mmap_sem in a sufficient amount of time,
> >
> > -
On Fri, 25 May 2018, Tetsuo Handa wrote:
> > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > it cannot reap an mm. This can happen for a variety of reasons,
> > including:
> >
> > - the inability to grab mm->mmap_sem in a sufficient amount of time,
> >
> > -
On Fri, 25 May 2018, Michal Hocko wrote:
> > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > it cannot reap an mm. This can happen for a variety of reasons,
> > including:
> >
> > - the inability to grab mm->mmap_sem in a sufficient amount of time,
> >
> > -
On Fri, 25 May 2018, Michal Hocko wrote:
> > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > it cannot reap an mm. This can happen for a variety of reasons,
> > including:
> >
> > - the inability to grab mm->mmap_sem in a sufficient amount of time,
> >
> > -
On Thu 24-05-18 14:22:53, David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm
On Thu 24-05-18 14:22:53, David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm
David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm has blockable mmu
David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm has blockable mmu
The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
it cannot reap an mm. This can happen for a variety of reasons,
including:
- the inability to grab mm->mmap_sem in a sufficient amount of time,
- when the mm has blockable mmu notifiers that could cause the oom reaper
The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
it cannot reap an mm. This can happen for a variety of reasons,
including:
- the inability to grab mm->mmap_sem in a sufficient amount of time,
- when the mm has blockable mmu notifiers that could cause the oom reaper
28 matches
Mail list logo
