On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does
> not
> solve your problem?
>
Such an invasive patch, and completely rewrites the oom reaper. I now
fully understand your frustration with the cgroup aware oom killer being
On Sat, 21 Jul 2018, Tetsuo Handa wrote:
> Why [PATCH 2/2] in https://marc.info/?l=linux-mm=153119509215026=4 does
> not
> solve your problem?
>
Such an invasive patch, and completely rewrites the oom reaper. I now
fully understand your frustration with the cgroup aware oom killer being
On 2018/07/21 5:19, David Rientjes wrote:
> On Fri, 20 Jul 2018, Tetsuo Handa wrote:
>
>>> Absent oom_lock serialization, this is exactly working as intended. You
>>> could argue that once the thread has reached exit_mmap() and begins oom
>>> reaping that it should be allowed to finish before
On 2018/07/21 5:19, David Rientjes wrote:
> On Fri, 20 Jul 2018, Tetsuo Handa wrote:
>
>>> Absent oom_lock serialization, this is exactly working as intended. You
>>> could argue that once the thread has reached exit_mmap() and begins oom
>>> reaping that it should be allowed to finish before
On Fri, 20 Jul 2018, Tetsuo Handa wrote:
> > Absent oom_lock serialization, this is exactly working as intended. You
> > could argue that once the thread has reached exit_mmap() and begins oom
> > reaping that it should be allowed to finish before the oom reaper declares
> > MMF_OOM_SKIP.
On Fri, 20 Jul 2018, Tetsuo Handa wrote:
> > Absent oom_lock serialization, this is exactly working as intended. You
> > could argue that once the thread has reached exit_mmap() and begins oom
> > reaping that it should be allowed to finish before the oom reaper declares
> > MMF_OOM_SKIP.
On 2018/07/20 17:41, David Rientjes wrote:
> Absent oom_lock serialization, this is exactly working as intended. You
> could argue that once the thread has reached exit_mmap() and begins oom
> reaping that it should be allowed to finish before the oom reaper declares
> MMF_OOM_SKIP. That
On 2018/07/20 17:41, David Rientjes wrote:
> Absent oom_lock serialization, this is exactly working as intended. You
> could argue that once the thread has reached exit_mmap() and begins oom
> reaping that it should be allowed to finish before the oom reaper declares
> MMF_OOM_SKIP. That
On Thu, 19 Jul 2018, Tetsuo Handa wrote:
> Sigh...
>
> Nacked-by: Tetsuo Handa
>
> because David is not aware what is wrong.
>
Hmm, didn't you incorporate this exact patch into your own patch series
that you proposed? :)
I'm coming to this stark realization that all of these theater is
On Thu, 19 Jul 2018, Tetsuo Handa wrote:
> Sigh...
>
> Nacked-by: Tetsuo Handa
>
> because David is not aware what is wrong.
>
Hmm, didn't you incorporate this exact patch into your own patch series
that you proposed? :)
I'm coming to this stark realization that all of these theater is
David,
Now that your patches are about to be dropped from linux-next.git , please try
OOM lockup
(CVE-2016-10723) mitigation patch (
https://marc.info/?l=linux-mm=153112243424285=4 )
and my cleanup patch ( [PATCH 1/2] at
https://marc.info/?l=linux-mm=153119509215026=4 )
on top of linux.git .
David,
Now that your patches are about to be dropped from linux-next.git , please try
OOM lockup
(CVE-2016-10723) mitigation patch (
https://marc.info/?l=linux-mm=153112243424285=4 )
and my cleanup patch ( [PATCH 1/2] at
https://marc.info/?l=linux-mm=153119509215026=4 )
on top of linux.git .
Sigh...
Nacked-by: Tetsuo Handa
because David is not aware what is wrong.
On 2018/07/19 5:22, David Rientjes wrote:
> On Wed, 18 Jul 2018, Tetsuo Handa wrote:
>
>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>> --- a/mm/mmap.c
>>> +++ b/mm/mmap.c
>>> @@ -3059,25 +3059,28 @@ void exit_mmap(struct
Sigh...
Nacked-by: Tetsuo Handa
because David is not aware what is wrong.
On 2018/07/19 5:22, David Rientjes wrote:
> On Wed, 18 Jul 2018, Tetsuo Handa wrote:
>
>>> diff --git a/mm/mmap.c b/mm/mmap.c
>>> --- a/mm/mmap.c
>>> +++ b/mm/mmap.c
>>> @@ -3059,25 +3059,28 @@ void exit_mmap(struct
On Wed, 18 Jul 2018, Tetsuo Handa wrote:
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -3059,25 +3059,28 @@ void exit_mmap(struct mm_struct *mm)
> > if (unlikely(mm_is_oom_victim(mm))) {
> > /*
> > * Manually reap the mm to free
On Wed, 18 Jul 2018, Tetsuo Handa wrote:
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -3059,25 +3059,28 @@ void exit_mmap(struct mm_struct *mm)
> > if (unlikely(mm_is_oom_victim(mm))) {
> > /*
> > * Manually reap the mm to free
This patch should be dropped from linux-next because it is incorrectly
using MMF_UNSTABLE.
On 2018/06/22 6:35, David Rientjes wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3059,25 +3059,28 @@ void exit_mmap(struct mm_struct *mm)
> if
This patch should be dropped from linux-next because it is incorrectly
using MMF_UNSTABLE.
On 2018/06/22 6:35, David Rientjes wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3059,25 +3059,28 @@ void exit_mmap(struct mm_struct *mm)
> if
On Mon 09-07-18 13:30:10, David Rientjes wrote:
> On Mon, 9 Jul 2018, Michal Hocko wrote:
>
> > > Blockable mmu notifiers and mlocked memory is not the extent of the
> > > problem, if a process has a lot of virtual memory we must wait until
> > > free_pgtables() completes in exit_mmap() to
On Mon 09-07-18 13:30:10, David Rientjes wrote:
> On Mon, 9 Jul 2018, Michal Hocko wrote:
>
> > > Blockable mmu notifiers and mlocked memory is not the extent of the
> > > problem, if a process has a lot of virtual memory we must wait until
> > > free_pgtables() completes in exit_mmap() to
On Mon, 9 Jul 2018, Michal Hocko wrote:
> > Blockable mmu notifiers and mlocked memory is not the extent of the
> > problem, if a process has a lot of virtual memory we must wait until
> > free_pgtables() completes in exit_mmap() to prevent unnecessary oom
> > killing. For implementations
On Mon, 9 Jul 2018, Michal Hocko wrote:
> > Blockable mmu notifiers and mlocked memory is not the extent of the
> > problem, if a process has a lot of virtual memory we must wait until
> > free_pgtables() completes in exit_mmap() to prevent unnecessary oom
> > killing. For implementations
On Fri 06-07-18 17:05:39, David Rientjes wrote:
[...]
> Blockable mmu notifiers and mlocked memory is not the extent of the
> problem, if a process has a lot of virtual memory we must wait until
> free_pgtables() completes in exit_mmap() to prevent unnecessary oom
> killing. For
On Fri 06-07-18 17:05:39, David Rientjes wrote:
[...]
> Blockable mmu notifiers and mlocked memory is not the extent of the
> problem, if a process has a lot of virtual memory we must wait until
> free_pgtables() completes in exit_mmap() to prevent unnecessary oom
> killing. For
On Thu, 5 Jul 2018, Andrew Morton wrote:
> > +#ifdef CONFIG_DEBUG_FS
> > +static int oom_free_timeout_ms_read(void *data, u64 *val)
> > +{
> > + *val = oom_free_timeout_ms;
> > + return 0;
> > +}
> > +
> > +static int oom_free_timeout_ms_write(void *data, u64 val)
> > +{
> > + if (val > 60
On Thu, 5 Jul 2018, Andrew Morton wrote:
> > +#ifdef CONFIG_DEBUG_FS
> > +static int oom_free_timeout_ms_read(void *data, u64 *val)
> > +{
> > + *val = oom_free_timeout_ms;
> > + return 0;
> > +}
> > +
> > +static int oom_free_timeout_ms_write(void *data, u64 val)
> > +{
> > + if (val > 60
On Thu 05-07-18 16:46:21, Andrew Morton wrote:
> On Thu, 21 Jun 2018 14:35:20 -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
On Thu 05-07-18 16:46:21, Andrew Morton wrote:
> On Thu, 21 Jun 2018 14:35:20 -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
On Thu, 21 Jun 2018 14:35:20 -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 Thu, 21 Jun 2018 14:35:20 -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,
>
David Rientjes wrote:
> Ping?
>
> This can be something that can easily be removed if it becomes obsoleted
> because the oom reaper is always able to free memory to the extent of
> exit_mmap(). I argue that it cannot, because it cannot do free_pgtables()
> for large amounts of virtual memory,
David Rientjes wrote:
> Ping?
>
> This can be something that can easily be removed if it becomes obsoleted
> because the oom reaper is always able to free memory to the extent of
> exit_mmap(). I argue that it cannot, because it cannot do free_pgtables()
> for large amounts of virtual memory,
Ping?
This can be something that can easily be removed if it becomes obsoleted
because the oom reaper is always able to free memory to the extent of
exit_mmap(). I argue that it cannot, because it cannot do free_pgtables()
for large amounts of virtual memory, but am fine to be proved wrong.
Ping?
This can be something that can easily be removed if it becomes obsoleted
because the oom reaper is always able to free memory to the extent of
exit_mmap(). I argue that it cannot, because it cannot do free_pgtables()
for large amounts of virtual memory, but am fine to be proved wrong.
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
36 matches
Mail list logo
