On Tue 06-08-19 19:26:12, Tetsuo Handa wrote:
> On 2019/08/05 23:26, Michal Hocko wrote:
> > On Mon 05-08-19 23:00:12, Tetsuo Handa wrote:
> >> On 2019/08/05 20:44, Michal Hocko wrote:
> Allowing forced charge due to being unable to invoke memcg OOM killer
> will lead to global OOM
On 2019/08/05 23:26, Michal Hocko wrote:
> On Mon 05-08-19 23:00:12, Tetsuo Handa wrote:
>> On 2019/08/05 20:44, Michal Hocko wrote:
Allowing forced charge due to being unable to invoke memcg OOM killer
will lead to global OOM situation, and just returning -ENOMEM will not
solve
On Mon 05-08-19 23:00:12, Tetsuo Handa wrote:
> On 2019/08/05 20:44, Michal Hocko wrote:
> >> Allowing forced charge due to being unable to invoke memcg OOM killer
> >> will lead to global OOM situation, and just returning -ENOMEM will not
> >> solve memcg OOM situation.
> >
> > Returning -ENOMEM
On 2019/08/05 20:44, Michal Hocko wrote:
>> Allowing forced charge due to being unable to invoke memcg OOM killer
>> will lead to global OOM situation, and just returning -ENOMEM will not
>> solve memcg OOM situation.
>
> Returning -ENOMEM would effectivelly lead to triggering the oom killer
>
On Mon 05-08-19 20:36:05, Tetsuo Handa wrote:
> I updated the changelog.
This looks much better, thanks! One nit
> >From 80b6f63b9d30df414e468e193a7f1b40c373ed68 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 5 Aug 2019 20:28:35 +0900
> Subject: [PATCH v2] memcg, oom: don't require
I updated the changelog.
>From 80b6f63b9d30df414e468e193a7f1b40c373ed68 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 5 Aug 2019 20:28:35 +0900
Subject: [PATCH v2] memcg, oom: don't require __GFP_FS when invoking memcg OOM
killer
Masoud Sharbiani noticed that commit 29ef680ae7c21110
On Sun 04-08-19 00:51:18, Tetsuo Handa wrote:
> Masoud, will you try this patch?
>
> By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
> non-zero
> despite /sys/fs/cgroup/memory/leaker/tasks became empty due to memcg OOM
> killer expected?
> Deleting big-data-file.bin
On Fri 02-08-19 16:28:25, Masoud Sharbiani wrote:
>
>
> > On Aug 2, 2019, at 12:14 PM, Michal Hocko wrote:
> >
> > On Fri 02-08-19 11:00:55, Masoud Sharbiani wrote:
> >>
> >>
> >>> On Aug 2, 2019, at 7:41 AM, Michal Hocko wrote:
> >>>
> >>> On Fri 02-08-19 07:18:17, Masoud Sharbiani wrote:
> On Aug 3, 2019, at 10:41 AM, Masoud Sharbiani wrote:
>
>
>
>> On Aug 3, 2019, at 8:51 AM, Tetsuo Handa
>> wrote:
>>
>> Masoud, will you try this patch?
>
> Gladly.
> It looks like it is working (and OOMing properly).
>
>
>>
>> By the way, is
> On Aug 3, 2019, at 8:51 AM, Tetsuo Handa
> wrote:
>
> Masoud, will you try this patch?
Gladly.
It looks like it is working (and OOMing properly).
>
> By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
> non-zero
> despite /sys/fs/cgroup/memory/leaker/tasks
Masoud, will you try this patch?
By the way, is /sys/fs/cgroup/memory/leaker/memory.usage_in_bytes remains
non-zero
despite /sys/fs/cgroup/memory/leaker/tasks became empty due to memcg OOM killer
expected?
Deleting big-data-file.bin after memcg OOM killer reduces some, but still
remains
Well, while mem_cgroup_oom() is actually called, due to hitting
/*
* The OOM killer does not compensate for IO-less reclaim.
* pagefault_out_of_memory lost its gfp context so we have to
* make sure exclude 0 mask - all other users should have at least
*
On Fri 02-08-19 11:00:55, Masoud Sharbiani wrote:
>
>
> > On Aug 2, 2019, at 7:41 AM, Michal Hocko wrote:
> >
> > On Fri 02-08-19 07:18:17, Masoud Sharbiani wrote:
> >>
> >>
> >>> On Aug 2, 2019, at 12:40 AM, Michal Hocko wrote:
> >>>
> >>> On Thu 01-08-19 11:04:14, Masoud Sharbiani wrote:
> On Aug 2, 2019, at 7:41 AM, Michal Hocko wrote:
>
> On Fri 02-08-19 07:18:17, Masoud Sharbiani wrote:
>>
>>
>>> On Aug 2, 2019, at 12:40 AM, Michal Hocko wrote:
>>>
>>> On Thu 01-08-19 11:04:14, Masoud Sharbiani wrote:
Hey folks,
I’ve come across an issue that affects most of
On Fri 02-08-19 07:18:17, Masoud Sharbiani wrote:
>
>
> > On Aug 2, 2019, at 12:40 AM, Michal Hocko wrote:
> >
> > On Thu 01-08-19 11:04:14, Masoud Sharbiani wrote:
> >> Hey folks,
> >> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2
> >> linux-stable kernels that has only
> On Aug 2, 2019, at 12:40 AM, Michal Hocko wrote:
>
> On Thu 01-08-19 11:04:14, Masoud Sharbiani wrote:
>> Hey folks,
>> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2
>> linux-stable kernels that has only been fixed in 5.3-rc1.
>> It was introduced by
>>
>> 29ef680
On Fri 02-08-19 20:10:58, Hillf Danton wrote:
>
> On Fri, 2 Aug 2019 16:18:40 +0800 Michal Hocko wrote:
[...]
> > Huh, what? You are effectively saying that we should fail the charge
> > when the requested nr_pages would fit in. This doesn't make much sense
> > to me. What are you trying to
[Hillf, your email client or workflow mangles emails. In this case you
are seem to be reusing the message id from the email you are replying to
which confuses my email client to assume your email is a duplicate.]
On Fri 02-08-19 16:08:01, Hillf Danton wrote:
[...]
> --- a/mm/memcontrol.c
> +++
On Thu 01-08-19 11:04:14, Masoud Sharbiani wrote:
> Hey folks,
> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2
> linux-stable kernels that has only been fixed in 5.3-rc1.
> It was introduced by
>
> 29ef680 memcg, oom: move out_of_memory back to the charge path
This commit
> On Aug 1, 2019, at 11:19 AM, Greg KH wrote:
>
> On Thu, Aug 01, 2019 at 11:04:14AM -0700, Masoud Sharbiani wrote:
>> Hey folks,
>> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2
>> linux-stable kernels that has only been fixed in 5.3-rc1.
>> It was introduced by
>>
>>
Hey folks,
I’ve come across an issue that affects most of 4.19, 4.20 and 5.2 linux-stable
kernels that has only been fixed in 5.3-rc1.
It was introduced by
29ef680 memcg, oom: move out_of_memory back to the charge path
The gist of it is that if you have a memory control group for a process
On Thu, Aug 01, 2019 at 11:04:14AM -0700, Masoud Sharbiani wrote:
> Hey folks,
> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2
> linux-stable kernels that has only been fixed in 5.3-rc1.
> It was introduced by
>
> 29ef680 memcg, oom: move out_of_memory back to the charge path
22 matches
Mail list logo
