From: Masoud Sharbiani <msharbiani@apple.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
hannes@cmpxchg.org, vdavydov.dev@gmail.com, linux-mm@kvack.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.
Date: Fri, 02 Aug 2019 16:28:25 -0700 [thread overview]
Message-ID: <A06C5313-B021-4ADA-9897-CE260A9011CC@apple.com> (raw)
In-Reply-To: <20190802191430.GO6461@dhcp22.suse.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2981 bytes --]
> On Aug 2, 2019, at 12:14 PM, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 02-08-19 11:00:55, Masoud Sharbiani wrote:
>>
>>
>>> On Aug 2, 2019, at 7:41 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Fri 02-08-19 07:18:17, Masoud Sharbiani wrote:
>>>>
>>>>
>>>>> On Aug 2, 2019, at 12:40 AM, Michal Hocko <mhocko@kernel.org> 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 memcg, oom: move out_of_memory back to the charge path
>>>>>
>>>>> This commit shouldn't really change the OOM behavior for your particular
>>>>> test case. It would have changed MAP_POPULATE behavior but your usage is
>>>>> triggering the standard page fault path. The only difference with
>>>>> 29ef680 is that the OOM killer is invoked during the charge path rather
>>>>> than on the way out of the page fault.
>>>>>
>>>>> Anyway, I tried to run your test case in a loop and leaker always ends
>>>>> up being killed as expected with 5.2. See the below oom report. There
>>>>> must be something else going on. How much swap do you have on your
>>>>> system?
>>>>
>>>> I do not have swap defined.
>>>
>>> OK, I have retested with swap disabled and again everything seems to be
>>> working as expected. The oom happens earlier because I do not have to
>>> wait for the swap to get full.
>>>
>>
>> In my tests (with the script provided), it only loops 11 iterations before hanging, and uttering the soft lockup message.
>>
>>
>>> Which fs do you use to write the file that you mmap?
>>
>> /dev/sda3 on / type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
>>
>> Part of the soft lockup path actually specifies that it is going through __xfs_filemap_fault():
>
> Right, I have just missed that.
>
> [...]
>
>> If I switch the backing file to a ext4 filesystem (separate hard drive), it OOMs.
>>
>>
>> If I switch the file used to /dev/zero, it OOMs:
>> …
>> Todal sum was 0. Loop count is 11
>> Buffer is @ 0x7f2b66c00000
>> ./test-script-devzero.sh: line 16: 3561 Killed ./leaker -p 10240 -c 100000
>>
>>
>>> Or could you try to
>>> simplify your test even further? E.g. does everything work as expected
>>> when doing anonymous mmap rather than file backed one?
>>
>> It also OOMs with MAP_ANON.
>>
>> Hope that helps.
>
> It helps to focus more on the xfs reclaim path. Just to be sure, is
> there any difference if you use cgroup v2? I do not expect to be but
> just to be sure there are no v1 artifacts.
I was unable to use cgroups2. I’ve created the new control group, but the attempt to move a running process into it fails with ‘Device or resource busy’.
Masoud
> --
> Michal Hocko
> SUSE Labs
[-- Attachment #1.2: Type: text/html, Size: 12878 bytes --]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3437 bytes --]
next prev parent reply other threads:[~2019-08-02 23:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 18:04 Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1 Masoud Sharbiani
2019-08-01 18:19 ` Greg KH
2019-08-01 22:26 ` Masoud Sharbiani
2019-08-02 1:08 ` Masoud Sharbiani
2019-08-02 8:08 ` Hillf Danton
2019-08-02 8:18 ` Michal Hocko
2019-08-02 7:40 ` Michal Hocko
2019-08-02 14:18 ` Masoud Sharbiani
2019-08-02 14:41 ` Michal Hocko
2019-08-02 18:00 ` Masoud Sharbiani
2019-08-02 19:14 ` Michal Hocko
2019-08-02 23:28 ` Masoud Sharbiani [this message]
2019-08-03 2:36 ` Tetsuo Handa
2019-08-03 15:51 ` Tetsuo Handa
2019-08-03 17:41 ` Masoud Sharbiani
2019-08-03 18:24 ` Masoud Sharbiani
2019-08-05 8:42 ` Michal Hocko
2019-08-05 11:36 ` Tetsuo Handa
2019-08-05 11:44 ` Michal Hocko
2019-08-05 14:00 ` Tetsuo Handa
2019-08-05 14:26 ` Michal Hocko
2019-08-06 10:26 ` Tetsuo Handa
2019-08-06 10:50 ` Michal Hocko
2019-08-06 12:48 ` [PATCH v3] memcg, oom: don't require __GFP_FS when invoking memcg OOM killer Tetsuo Handa
2019-08-05 8:18 ` Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1 Michal Hocko
2019-08-02 12:10 Hillf Danton
2019-08-02 13:40 ` Michal Hocko
2019-08-03 5:45 Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A06C5313-B021-4ADA-9897-CE260A9011CC@apple.com \
--to=msharbiani@apple.com \
--cc=cgroups@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).