On Fri 22-06-18 11:49:14, David Rientjes wrote:
> On Fri, 22 Jun 2018, Michal Hocko wrote:
>
> > > > preempt_disable() is required because it calls kvm_kick_many_cpus()
> > > > with
> > > > wait == true because KVM_REQ_APIC_PAGE_RELOAD sets KVM_REQUEST_WAIT and
> > > > thus the smp_call_functio
On 2018/06/15 5:42, David Rientjes wrote:
> Note: I understand there is an objection based on timeout based delays.
> This is currently the only possible way to avoid oom killing important
> processes completely unnecessarily. If the oom reaper can someday free
> all memory, including mlocked
On Fri, 22 Jun 2018, Michal Hocko wrote:
> > > preempt_disable() is required because it calls kvm_kick_many_cpus() with
> > > wait == true because KVM_REQ_APIC_PAGE_RELOAD sets KVM_REQUEST_WAIT and
> > > thus the smp_call_function_many() is going to block until all cpus can
> > > run
> > > ack
On Fri 22-06-18 09:42:57, Michal Hocko wrote:
> On Thu 21-06-18 13:50:53, David Rientjes wrote:
> > On Thu, 21 Jun 2018, Michal Hocko wrote:
> >
> > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > > index 6bcecc325e7e..ac08f5d711be 100644
> > > > > --- a/arch/x86/kvm/x86.c
> > >
On Thu 21-06-18 13:50:53, David Rientjes wrote:
> On Thu, 21 Jun 2018, Michal Hocko wrote:
>
> > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > > index 6bcecc325e7e..ac08f5d711be 100644
> > > > --- a/arch/x86/kvm/x86.c
> > > > +++ b/arch/x86/kvm/x86.c
> > > > @@ -7203,8 +7203,9 @@
On Thu, 21 Jun 2018, Michal Hocko wrote:
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 6bcecc325e7e..ac08f5d711be 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -7203,8 +7203,9 @@ static void vcpu_load_eoi_exitmap(struct kvm_vcpu
> > > *vcpu
On Thu 21-06-18 09:45:37, Michal Hocko wrote:
> On Wed 20-06-18 13:34:52, David Rientjes wrote:
> > On Wed, 20 Jun 2018, Michal Hocko wrote:
[...]
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 6bcecc325e7e..ac08f5d711be 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch
On Wed 20-06-18 13:34:52, David Rientjes wrote:
> On Wed, 20 Jun 2018, Michal Hocko wrote:
>
> > On Tue 19-06-18 10:33:16, Michal Hocko wrote:
> > [...]
> > > As I've said, if you are not willing to work on a proper solution, I
> > > will, but my nack holds for this patch until we see no other way
On Wed, 20 Jun 2018, Michal Hocko wrote:
> On Tue 19-06-18 10:33:16, Michal Hocko wrote:
> [...]
> > As I've said, if you are not willing to work on a proper solution, I
> > will, but my nack holds for this patch until we see no other way around
> > existing and real world problems.
>
> OK, so I
On Tue 19-06-18 10:33:16, Michal Hocko wrote:
[...]
> As I've said, if you are not willing to work on a proper solution, I
> will, but my nack holds for this patch until we see no other way around
> existing and real world problems.
OK, so I gave it a quick try and it doesn't look all that bad to
On Mon, 18 Jun 2018, Andrew Morton 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,
> >
> > - whe
On Mon 18-06-18 17:27:33, Andrew Morton wrote:
> On Thu, 14 Jun 2018 13:42:59 -0700 (PDT) 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 in
On Fri 15-06-18 16:15:39, David Rientjes wrote:
[...]
> I'd be happy to make the this timeout configurable, however, and default
> it to perhaps one second as the blockable mmu notifier timeout in your own
> code does. I find it somewhat sad that we'd need a sysctl for this, but
> if that will
On Thu, 14 Jun 2018 13:42:59 -0700 (PDT) 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,
>
On Fri, 15 Jun 2018, Michal Hocko wrote:
> > Signed-off-by: David Rientjes
>
> Nacked-by: Michal Hocko
> as already explained elsewhere in this email thread.
>
I don't find this to be surprising, but I'm not sure that it actually
matters if you won't fix a regression that you introduced. Te
On Thu 14-06-18 13:42:59, 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
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
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 hog
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 that
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 ori
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 mm,
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 MM
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.
>
> Cou
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 grab
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,
> >
> > - when
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,
> >
> > - when
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 notifier
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
31 matches
Mail list logo