Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: 866b485262173a2b873386162b2ddcfbcb542b4a ("mm/page_owner: record the timestamp of all pages during free")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
version: trinity-static-i386-x86_64-f93256fb_2019-08-28
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+---------------------------------------------------------+------------+------------+
| | 0b5121ef85 | 866b485262 |
+---------------------------------------------------------+------------+------------+
| boot_successes | 25 | 0 |
| boot_failures | 0 | 28 |
| invoked_oom-killer:gfp_mask=0x | 0 | 28 |
| Mem-Info | 0 | 28 |
| Out_of_memory_and_no_killable_processes | 0 | 28 |
| Kernel_panic-not_syncing:System_is_deadlocked_on_memory | 0 | 28 |
+---------------------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
[ 291.773251][ C0] CE: hpet increased min_delta_ns to 7500 nsec
[ 291.773294][ C0] CE: hpet increased min_delta_ns to 11250 nsec
[ 292.081092][ C0] CE: hpet increased min_delta_ns to 16875 nsec
[ 292.081236][ C0] CE: hpet increased min_delta_ns to 25312 nsec
[ 292.081408][ C0] CE: hpet increased min_delta_ns to 37968 nsec
[ 292.359657][ T1] swapper invoked oom-killer: gfp_mask=0x100cc0(GFP_USER), order=0, oom_score_adj=0
[ 292.360692][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.12.0-11178-g866b48526217 #1
[ 292.361945][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
[ 292.362811][ T1] Call Trace:
[ 292.363140][ T1] dump_stack (kbuild/src/consumer/lib/dump_stack.c:131)
[ 292.363551][ T1] dump_header (kbuild/src/consumer/mm/oom_kill.c:463)
[ 292.363969][ T1] ? out_of_memory (kbuild/src/consumer/include/linux/rcupdate.h:710 kbuild/src/consumer/mm/oom_kill.c:379 kbuild/src/consumer/mm/oom_kill.c:1102 kbuild/src/consumer/mm/oom_kill.c:1048)
[ 292.364439][ T1] out_of_memory.cold (kbuild/src/consumer/mm/oom_kill.c:1106 kbuild/src/consumer/mm/oom_kill.c:1048)
[ 292.365422][ T1] __alloc_pages_slowpath+0x73e/0xbc0
To reproduce:
# build kernel
cd linux
cp config-5.12.0-11178-g866b48526217 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare modules_prepare bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
---
0DAY/LKP+ Test Infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Thanks,
Oliver Sang
On Thu, 29 Jul 2021 09:40:19 +0800 kernel test robot <[email protected]> wrote:
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 866b485262173a2b873386162b2ddcfbcb542b4a ("mm/page_owner: record the timestamp of all pages during free")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
I don't see how this can happen unless it's a side-effect of making
struct page_owner 8 bytes larger. Does setting
/proc/sys/vm/oom_dump_tasks tell us more?
On 7/29/21 8:46 PM, Andrew Morton wrote:
> On Thu, 29 Jul 2021 09:40:19 +0800 kernel test robot <[email protected]> wrote:
>
>>
>>
>> Greeting,
>>
>> FYI, we noticed the following commit (built with gcc-9):
>>
>> commit: 866b485262173a2b873386162b2ddcfbcb542b4a ("mm/page_owner: record the timestamp of all pages during free")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> I don't see how this can happen unless it's a side-effect of making
> struct page_owner 8 bytes larger.
It's possible. Seems to be a 32bit highmem kernel, allocation that fails is
GFP_USER and the page_owner (part of page_ext) has to be in lowmem, even for
highmem pages, and there's not an insignificant amount of it:
[ 16.228923][ T0] allocated 178298840 bytes of page_ext
Seems to be one of the cases where contemporary kernel features are not always
suitable for 32bit kernels (especially with large memory). The highmem is 16GB.
If it was smaller, it would be actually better.
> Does setting
> /proc/sys/vm/oom_dump_tasks tell us more?
>