Hi,
I was just wondering the process of the patch "oom reaper: handle
mlocked pages".
links:
https://lore.kernel.org/linux-mm/[email protected]/
https://lore.kernel.org/linux-mm/[email protected]/
In linux master, we found that when we start a process and alloc large
memory with MAP_LOCKED, the oom will triggered and kill some system
process such as sshd ,rsyslog etc.
...
[ 45.110665] Out of memory: Killed process 2551 (oom)
total-vm:1035324kB, anon-rss:1028196kB, file-rss:704kB, shmem-rss:0kB,
UID:0 pgtables:2056kB oom_score_adj:1000
[ 45.115303] Out of memory: Killed process 2554 (oom)
total-vm:1025084kB, anon-rss:1015596kB, file-rss:388kB, shmem-rss:0kB,
UID:0 pgtables:2032kB oom_score_adj:1000
[ 45.115685] Out of memory: Killed process 2553 (oom)
total-vm:953404kB, anon-rss:947748kB, file-rss:388kB, shmem-rss:0kB,
UID:0 pgtables:1896kB oom_score_adj:1000
[ 45.116031] Out of memory: Killed process 2552 (oom)
total-vm:789564kB, anon-rss:783272kB, file-rss:388kB, shmem-rss:0kB,
UID:0 pgtables:1576kB oom_score_adj:1000
[ 45.117199] Out of memory: Killed process 2523 (sshd)
total-vm:77052kB, anon-rss:804kB, file-rss:4672kB, shmem-rss:4kB, UID:0
pgtables:196kB oom_score_adj:0
[ 45.120936] Out of memory: Killed process 2526 (bash)
total-vm:17792kB, anon-rss:1180kB, file-rss:2868kB, shmem-rss:0kB, UID:0
pgtables:76kB oom_score_adj:0
...
the process demo is:
...
#define ALLOC_SIZE (10 * 1024 * 1024)
while (1) {
addr = mmap(NULL, ALLOC_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS | MAP_LOCKED, -1, 0);
if (addr != MAP_FAILED)
memset(addr, 1, ALLOC_SIZE);
}
...
And we found that when the oom_reaper is done but the memory is still high:
[ 45.115685] Out of memory: Killed process 2553 (oom)
total-vm:953404kB, anon-rss:947748kB, file-rss:388kB, shmem-rss:0kB,
UID:0 pgtables:1896kB oom_score_adj:1000
[ 45.115739] oom_reaper: reaped process 2553 (oom), now
anon-rss:947708kB, file-rss:0kB, shmem-rss:0kB
This is because the bad proccess which recieved SIGKILL is unlocking the
mem to exit which needs more time. And the next oom is triggered to kill
the other system process.
Kind regards,
Yongqiang Liu
Hi,
On Mon 01-11-21 16:05:50, Yongqiang Liu wrote:
[...]
> And we found that when the oom_reaper is done but the memory is still high:
>
> [?? 45.115685] Out of memory: Killed process 2553 (oom) total-vm:953404kB,
> anon-rss:947748kB, file-rss:388kB, shmem-rss:0kB, UID:0 pgtables:1896kB
> oom_score_adj:1000
> [?? 45.115739] oom_reaper: reaped process 2553 (oom), now anon-rss:947708kB,
> file-rss:0kB, shmem-rss:0kB
>
> This is because the bad proccess which recieved SIGKILL is unlocking the mem
> to exit which needs more time. And the next oom is triggered to kill the
> other system process.
Yes, this is a known limitation of the oom_reaper based OOM killing.
__oom_reap_task_mm has to skip over mlocked memory areas because
munlocking requires some locking (or at least that was the case when the
oom reaper was introduced) and the primary purpose of the oom_reaper is
to guarantee a forward progress.
Addressing that limitation would require the munlock operation to not
depend on any locking. I am not sure how much work that would be with
the current code. Until now this was not a high priority because
processes with a high mlock limit should be really trusted with their
memory consumption so they shouldn't be really the primary oom killer
target.
Are you seeing this problem happening with a real workload or is this
only triggered with some artificial tests? E.g. LTP oom tests are known
to trigger this situation but they do not represent any real workload.
--
Michal Hocko
SUSE Labs
在 2021/11/1 16:24, Michal Hocko 写道:
> Hi,
>
> On Mon 01-11-21 16:05:50, Yongqiang Liu wrote:
> [...]
>> And we found that when the oom_reaper is done but the memory is still high:
>>
>> [ 45.115685] Out of memory: Killed process 2553 (oom) total-vm:953404kB,
>> anon-rss:947748kB, file-rss:388kB, shmem-rss:0kB, UID:0 pgtables:1896kB
>> oom_score_adj:1000
>> [ 45.115739] oom_reaper: reaped process 2553 (oom), now anon-rss:947708kB,
>> file-rss:0kB, shmem-rss:0kB
>>
>> This is because the bad proccess which recieved SIGKILL is unlocking the mem
>> to exit which needs more time. And the next oom is triggered to kill the
>> other system process.
> Yes, this is a known limitation of the oom_reaper based OOM killing.
> __oom_reap_task_mm has to skip over mlocked memory areas because
> munlocking requires some locking (or at least that was the case when the
> oom reaper was introduced) and the primary purpose of the oom_reaper is
> to guarantee a forward progress.
>
> Addressing that limitation would require the munlock operation to not
> depend on any locking. I am not sure how much work that would be with
> the current code. Until now this was not a high priority because
> processes with a high mlock limit should be really trusted with their
> memory consumption so they shouldn't be really the primary oom killer
> target.
>
> Are you seeing this problem happening with a real workload or is this
> only triggered with some artificial tests? E.g. LTP oom tests are known
> to trigger this situation but they do not represent any real workload.
I haven't found it in real workload yet. It's just a testcase.
--
Yongqiang Liu