Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/28/2018 12:58 AM, Minchan Kim wrote: I made a mistake on previous patch. Could you test this patches? Thanks! Looking good so far! No errors whatsoever with the new patch. I will let my test workload running for while to be sure, but I think we are good. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/28/2018 12:58 AM, Minchan Kim wrote: I made a mistake on previous patch. Could you test this patches? Thanks! Looking good so far! No errors whatsoever with the new patch. I will let my test workload running for while to be sure, but I think we are good. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/27/2018 02:05 PM, Minchan Kim wrote: And bad page is always with writeback enable? writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev, not just enable CONFIG_ZRAM_WRITEBACK. Yes, the bug only appears when backing_dev is set. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/27/2018 02:05 PM, Minchan Kim wrote: And bad page is always with writeback enable? writeback enable means "echo "some dev" > /sys/block/zram0/backing_dev, not just enable CONFIG_ZRAM_WRITEBACK. Yes, the bug only appears when backing_dev is set. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/27/2018 11:14 AM, Minchan Kim wrote: I tried to reproduce with KVM but was not successful and I don't have real mahcine to reproduce it. I am asking one device for it. Anyway, I want to try this patch. Could you apply attached two patches? Thanks, I applied the patches on 4.18-rc6, but unfortunately, they do not solve the problem for me. Kernel message below. I am confusing. You mean after 4.15-rc9, you are not seeing*hung* problem? Correct. So you mean you see page state bug with recent kernel right? It seems there are two problems now. 1. Hung and 2. bad page What bugs between them happens against what kernel version? Could you clarify it? * pre 0bcac06f27d75 (4.15-rc1): all good * 4.15-rc1: hung task (I have not encountered bad page here yet...) * 4.15-rc2 through 4.15-rc8: hung task + bad page (very rare) * 4.15-rc9 and newer: bad page -- [ 809.149272] BUG: Bad page state in process kvm pfn:1cb08a8 [ 809.149332] flags: 0x57c008(uptodate) [ 809.149350] raw: 0057c008 dead0100 dead0200 [ 809.149378] raw: 0001 [ 809.149405] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 809.149427] bad because of flags: 0x8(uptodate) [ 809.149444] Modules linked in: lz4 lz4_compress zram [ 809.149450] CPU: 14 PID: 3734 Comm: kvm Not tainted 4.18.0-rc6+ #1 [ 809.149450] Hardware name: Supermicro Super Server/X10DRL-i, BIOS 3.0a 02/09/2018 [ 809.149451] Call Trace: [ 809.149458] dump_stack+0x63/0x85 [ 809.149463] bad_page+0xc1/0x120 [ 809.149465] check_new_page_bad+0x67/0x80 [ 809.149467] get_page_from_freelist+0xe25/0x12f0 [ 809.149469] __alloc_pages_nodemask+0xfd/0x280 [ 809.149472] alloc_pages_vma+0x88/0x1c0 [ 809.149475] do_swap_page+0x346/0x910 [ 809.149477] __handle_mm_fault+0x815/0x1170 [ 809.149479] handle_mm_fault+0x102/0x200 [ 809.149481] __get_user_pages+0x131/0x680 [ 809.149483] get_user_pages_unlocked+0x145/0x1e0 [ 809.149488] __gfn_to_pfn_memslot+0x10b/0x3c0 [ 809.149491] try_async_pf+0x86/0x230 [ 809.149494] tdp_page_fault+0x12d/0x290 [ 809.149496] kvm_mmu_page_fault+0x74/0x5d0 [ 809.149499] ? call_function_interrupt+0xa/0x20 [ 809.149502] ? vmexit_fill_RSB+0x10/0x40 [ 809.149503] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149504] ? vmexit_fill_RSB+0x10/0x40 [ 809.149505] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149506] ? vmexit_fill_RSB+0x10/0x40 [ 809.149507] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149508] ? vmexit_fill_RSB+0x10/0x40 [ 809.149509] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149510] ? vmexit_fill_RSB+0x10/0x40 [ 809.149513] handle_ept_violation+0xdf/0x1a0 [ 809.149514] vmx_handle_exit+0xa5/0x11c0 [ 809.149516] ? vmx_vcpu_run+0x3bb/0x620 [ 809.149519] kvm_arch_vcpu_ioctl_run+0x9b3/0x1980 [ 809.149522] kvm_vcpu_ioctl+0x3a0/0x5e0 [ 809.149523] ? kvm_vcpu_ioctl+0x3a0/0x5e0 [ 809.149526] do_vfs_ioctl+0xa6/0x620 [ 809.149527] ksys_ioctl+0x75/0x80 [ 809.149529] __x64_sys_ioctl+0x1a/0x20 [ 809.149532] do_syscall_64+0x5a/0x110 [ 809.149534] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 809.149536] RIP: 0033:0x7fd3c5572dd7 [ 809.149536] Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 80 2b 00 f7 d8 64 89 01 48 [ 809.149563] RSP: 002b:7fd3b07fc538 EFLAGS: 0246 ORIG_RAX: 0010 [ 809.149565] RAX: ffda RBX: ae80 RCX: 7fd3c5572dd7 [ 809.149566] RDX: RSI: ae80 RDI: 0014 [ 809.149566] RBP: 7fd3b9b13000 R08: 558cb94bb350 R09: [ 809.149567] R10: 0005577fd3b06fe6 R11: 0246 R12: [ 809.149568] R13: 7fd3ba146000 R14: R15: 7fd3b9b13000 [ 809.149570] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/27/2018 11:14 AM, Minchan Kim wrote: I tried to reproduce with KVM but was not successful and I don't have real mahcine to reproduce it. I am asking one device for it. Anyway, I want to try this patch. Could you apply attached two patches? Thanks, I applied the patches on 4.18-rc6, but unfortunately, they do not solve the problem for me. Kernel message below. I am confusing. You mean after 4.15-rc9, you are not seeing*hung* problem? Correct. So you mean you see page state bug with recent kernel right? It seems there are two problems now. 1. Hung and 2. bad page What bugs between them happens against what kernel version? Could you clarify it? * pre 0bcac06f27d75 (4.15-rc1): all good * 4.15-rc1: hung task (I have not encountered bad page here yet...) * 4.15-rc2 through 4.15-rc8: hung task + bad page (very rare) * 4.15-rc9 and newer: bad page -- [ 809.149272] BUG: Bad page state in process kvm pfn:1cb08a8 [ 809.149332] flags: 0x57c008(uptodate) [ 809.149350] raw: 0057c008 dead0100 dead0200 [ 809.149378] raw: 0001 [ 809.149405] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 809.149427] bad because of flags: 0x8(uptodate) [ 809.149444] Modules linked in: lz4 lz4_compress zram [ 809.149450] CPU: 14 PID: 3734 Comm: kvm Not tainted 4.18.0-rc6+ #1 [ 809.149450] Hardware name: Supermicro Super Server/X10DRL-i, BIOS 3.0a 02/09/2018 [ 809.149451] Call Trace: [ 809.149458] dump_stack+0x63/0x85 [ 809.149463] bad_page+0xc1/0x120 [ 809.149465] check_new_page_bad+0x67/0x80 [ 809.149467] get_page_from_freelist+0xe25/0x12f0 [ 809.149469] __alloc_pages_nodemask+0xfd/0x280 [ 809.149472] alloc_pages_vma+0x88/0x1c0 [ 809.149475] do_swap_page+0x346/0x910 [ 809.149477] __handle_mm_fault+0x815/0x1170 [ 809.149479] handle_mm_fault+0x102/0x200 [ 809.149481] __get_user_pages+0x131/0x680 [ 809.149483] get_user_pages_unlocked+0x145/0x1e0 [ 809.149488] __gfn_to_pfn_memslot+0x10b/0x3c0 [ 809.149491] try_async_pf+0x86/0x230 [ 809.149494] tdp_page_fault+0x12d/0x290 [ 809.149496] kvm_mmu_page_fault+0x74/0x5d0 [ 809.149499] ? call_function_interrupt+0xa/0x20 [ 809.149502] ? vmexit_fill_RSB+0x10/0x40 [ 809.149503] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149504] ? vmexit_fill_RSB+0x10/0x40 [ 809.149505] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149506] ? vmexit_fill_RSB+0x10/0x40 [ 809.149507] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149508] ? vmexit_fill_RSB+0x10/0x40 [ 809.149509] ? vmexit_fill_RSB+0x1c/0x40 [ 809.149510] ? vmexit_fill_RSB+0x10/0x40 [ 809.149513] handle_ept_violation+0xdf/0x1a0 [ 809.149514] vmx_handle_exit+0xa5/0x11c0 [ 809.149516] ? vmx_vcpu_run+0x3bb/0x620 [ 809.149519] kvm_arch_vcpu_ioctl_run+0x9b3/0x1980 [ 809.149522] kvm_vcpu_ioctl+0x3a0/0x5e0 [ 809.149523] ? kvm_vcpu_ioctl+0x3a0/0x5e0 [ 809.149526] do_vfs_ioctl+0xa6/0x620 [ 809.149527] ksys_ioctl+0x75/0x80 [ 809.149529] __x64_sys_ioctl+0x1a/0x20 [ 809.149532] do_syscall_64+0x5a/0x110 [ 809.149534] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 809.149536] RIP: 0033:0x7fd3c5572dd7 [ 809.149536] Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 80 2b 00 f7 d8 64 89 01 48 [ 809.149563] RSP: 002b:7fd3b07fc538 EFLAGS: 0246 ORIG_RAX: 0010 [ 809.149565] RAX: ffda RBX: ae80 RCX: 7fd3c5572dd7 [ 809.149566] RDX: RSI: ae80 RDI: 0014 [ 809.149566] RBP: 7fd3b9b13000 R08: 558cb94bb350 R09: [ 809.149567] R10: 0005577fd3b06fe6 R11: 0246 R12: [ 809.149568] R13: 7fd3ba146000 R14: R15: 7fd3b9b13000 [ 809.149570] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
50 [ 363.118898] __gfn_to_pfn_memslot+0xff/0x3d0 [ 363.118903] try_async_pf+0x53/0x1d0 [ 363.118907] tdp_page_fault+0x10e/0x260 [ 363.118912] ? vmexit_fill_RSB+0x11/0x30 [ 363.118915] kvm_mmu_page_fault+0x59/0x130 [ 363.118920] vmx_handle_exit+0x9f/0x1530 [ 363.118924] ? vmexit_fill_RSB+0x11/0x30 [ 363.118927] ? vmx_vcpu_run+0x32f/0x4d0 [ 363.118932] kvm_arch_vcpu_ioctl_run+0x90c/0x1670 [ 363.118936] ? handle_machine_check+0x10/0x10 [ 363.118938] ? kvm_arch_vcpu_load+0x68/0x250 [ 363.118943] ? kvm_vcpu_ioctl+0x2e8/0x580 [ 363.118946] kvm_vcpu_ioctl+0x2e8/0x580 [ 363.118952] do_vfs_ioctl+0x92/0x5f0 [ 363.118955] ? handle_mm_fault+0xc6/0x1b0 [ 363.118960] ? kvm_on_user_return+0x68/0xa0 [ 363.118964] SyS_ioctl+0x74/0x80 [ 363.118969] entry_SYSCALL_64_fastpath+0x24/0x87 [ 363.118972] RIP: 0033:0x7fcc51943dd7 -- [ 967.078557] BUG: Bad page state in process qemu-system-x86 pfn:3f6d853 [ 967.078637] page:4d26db38 count:0 mapcount:0 mapping: (null) index:0x1 [ 967.078715] flags: 0x17fffc8(uptodate) [ 967.078786] raw: 017fffc8 0001 [ 967.078863] raw: dead0100 dead0200 [ 967.078939] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 967.079012] bad because of flags: 0x8(uptodate) [ 967.079081] Modules linked in: lz4 lz4_compress zram [ 967.079085] CPU: 2 PID: 946 Comm: qemu-system-x86 Not tainted 4.15.0-rc2-zram #4 [ 967.079086] Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017 [ 967.079087] Call Trace: [ 967.079093] dump_stack+0x5c/0x84 [ 967.079097] bad_page+0xba/0x120 [ 967.079098] get_page_from_freelist+0xfe7/0x1230 [ 967.079101] __alloc_pages_nodemask+0xea/0x230 [ 967.079104] alloc_pages_vma+0x7c/0x1c0 [ 967.079106] do_swap_page+0x474/0x870 [ 967.079109] ? do_huge_pmd_anonymous_page+0x417/0x610 [ 967.079110] __handle_mm_fault+0xa53/0x1160 [ 967.079112] handle_mm_fault+0xc6/0x1b0 [ 967.079114] __get_user_pages+0xf9/0x620 [ 967.079117] get_user_pages+0x3e/0x50 [ 967.079119] __gfn_to_pfn_memslot+0xff/0x3d0 [ 967.079122] try_async_pf+0x53/0x1c0 [ 967.079124] tdp_page_fault+0x10e/0x260 [ 967.079125] kvm_mmu_page_fault+0x53/0x130 [ 967.079128] vmx_handle_exit+0x9c/0x1500 [ 967.079129] ? atomic_switch_perf_msrs+0x5f/0x80 [ 967.079130] ? vmx_vcpu_run+0x30a/0x4b0 [ 967.079133] kvm_arch_vcpu_ioctl_run+0x8dc/0x15e0 [ 967.079135] ? kvm_arch_vcpu_load+0x62/0x230 [ 967.079136] ? kvm_vcpu_ioctl+0x2e8/0x580 [ 967.079137] kvm_vcpu_ioctl+0x2e8/0x580 [ 967.079141] ? wake_up_q+0x70/0x70 [ 967.079144] do_vfs_ioctl+0x8f/0x5e0 [ 967.079147] ? kvm_on_user_return+0x68/0xa0 [ 967.079148] SyS_ioctl+0x74/0x80 [ 967.079152] entry_SYSCALL_64_fastpath+0x1e/0x81 [ 967.079154] RIP: 0033:0x7f4410161dd7 [ 967.079154] RSP: 002b:7f43eeffc8b8 EFLAGS: 0246 ORIG_RAX: 0010 [ 967.079156] RAX: ffda RBX: ae80 RCX: 7f4410161dd7 [ 967.079156] RDX: RSI: ae80 RDI: 0013 [ 967.079157] RBP: 55c5a36f8e50 R08: 55c5a0fa73d0 R09: [ 967.079158] R10: 003b83305f306bdf R11: 0246 R12: [ 967.079158] R13: 7f44157ad000 R14: R15: 55c5a36f8e50 [ 967.079160] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
50 [ 363.118898] __gfn_to_pfn_memslot+0xff/0x3d0 [ 363.118903] try_async_pf+0x53/0x1d0 [ 363.118907] tdp_page_fault+0x10e/0x260 [ 363.118912] ? vmexit_fill_RSB+0x11/0x30 [ 363.118915] kvm_mmu_page_fault+0x59/0x130 [ 363.118920] vmx_handle_exit+0x9f/0x1530 [ 363.118924] ? vmexit_fill_RSB+0x11/0x30 [ 363.118927] ? vmx_vcpu_run+0x32f/0x4d0 [ 363.118932] kvm_arch_vcpu_ioctl_run+0x90c/0x1670 [ 363.118936] ? handle_machine_check+0x10/0x10 [ 363.118938] ? kvm_arch_vcpu_load+0x68/0x250 [ 363.118943] ? kvm_vcpu_ioctl+0x2e8/0x580 [ 363.118946] kvm_vcpu_ioctl+0x2e8/0x580 [ 363.118952] do_vfs_ioctl+0x92/0x5f0 [ 363.118955] ? handle_mm_fault+0xc6/0x1b0 [ 363.118960] ? kvm_on_user_return+0x68/0xa0 [ 363.118964] SyS_ioctl+0x74/0x80 [ 363.118969] entry_SYSCALL_64_fastpath+0x24/0x87 [ 363.118972] RIP: 0033:0x7fcc51943dd7 -- [ 967.078557] BUG: Bad page state in process qemu-system-x86 pfn:3f6d853 [ 967.078637] page:4d26db38 count:0 mapcount:0 mapping: (null) index:0x1 [ 967.078715] flags: 0x17fffc8(uptodate) [ 967.078786] raw: 017fffc8 0001 [ 967.078863] raw: dead0100 dead0200 [ 967.078939] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 967.079012] bad because of flags: 0x8(uptodate) [ 967.079081] Modules linked in: lz4 lz4_compress zram [ 967.079085] CPU: 2 PID: 946 Comm: qemu-system-x86 Not tainted 4.15.0-rc2-zram #4 [ 967.079086] Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017 [ 967.079087] Call Trace: [ 967.079093] dump_stack+0x5c/0x84 [ 967.079097] bad_page+0xba/0x120 [ 967.079098] get_page_from_freelist+0xfe7/0x1230 [ 967.079101] __alloc_pages_nodemask+0xea/0x230 [ 967.079104] alloc_pages_vma+0x7c/0x1c0 [ 967.079106] do_swap_page+0x474/0x870 [ 967.079109] ? do_huge_pmd_anonymous_page+0x417/0x610 [ 967.079110] __handle_mm_fault+0xa53/0x1160 [ 967.079112] handle_mm_fault+0xc6/0x1b0 [ 967.079114] __get_user_pages+0xf9/0x620 [ 967.079117] get_user_pages+0x3e/0x50 [ 967.079119] __gfn_to_pfn_memslot+0xff/0x3d0 [ 967.079122] try_async_pf+0x53/0x1c0 [ 967.079124] tdp_page_fault+0x10e/0x260 [ 967.079125] kvm_mmu_page_fault+0x53/0x130 [ 967.079128] vmx_handle_exit+0x9c/0x1500 [ 967.079129] ? atomic_switch_perf_msrs+0x5f/0x80 [ 967.079130] ? vmx_vcpu_run+0x30a/0x4b0 [ 967.079133] kvm_arch_vcpu_ioctl_run+0x8dc/0x15e0 [ 967.079135] ? kvm_arch_vcpu_load+0x62/0x230 [ 967.079136] ? kvm_vcpu_ioctl+0x2e8/0x580 [ 967.079137] kvm_vcpu_ioctl+0x2e8/0x580 [ 967.079141] ? wake_up_q+0x70/0x70 [ 967.079144] do_vfs_ioctl+0x8f/0x5e0 [ 967.079147] ? kvm_on_user_return+0x68/0xa0 [ 967.079148] SyS_ioctl+0x74/0x80 [ 967.079152] entry_SYSCALL_64_fastpath+0x1e/0x81 [ 967.079154] RIP: 0033:0x7f4410161dd7 [ 967.079154] RSP: 002b:7f43eeffc8b8 EFLAGS: 0246 ORIG_RAX: 0010 [ 967.079156] RAX: ffda RBX: ae80 RCX: 7f4410161dd7 [ 967.079156] RDX: RSI: ae80 RDI: 0013 [ 967.079157] RBP: 55c5a36f8e50 R08: 55c5a0fa73d0 R09: [ 967.079158] R10: 003b83305f306bdf R11: 0246 R12: [ 967.079158] R13: 7f44157ad000 R14: R15: 55c5a36f8e50 [ 967.079160] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/26/2018 08:10 AM, Tino Lehnig wrote: A thing I could imagine is [0bcac06f27d75, skip swapcache for swapin of synchronous device] It was merged into v4.15. Could you check it by bisecting? Thanks, I will check that. So I get the same behavior as in v4.15-rc1 after this commit. All prior builds are fine. I have also tested all other 4.15 rc builds now and the symptoms are the same through rc8. KVM processes become unresponsive and I see kernel messages like the one below. This happens with and without the writeback feature being used. The bad page state bug appears very rarely in these versions and only when writeback is active. Starting with rc9, I only get the same bad page state bug as in all newer kernels. -- [ 363.494793] INFO: task kworker/4:2:498 blocked for more than 120 seconds. [ 363.494872] Not tainted 4.14.0-zram-pre-rc1 #17 [ 363.494943] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 363.495021] kworker/4:2 D0 498 2 0x8000 [ 363.495029] Workqueue: events async_pf_execute [ 363.495030] Call Trace: [ 363.495037] ? __schedule+0x3bc/0x830 [ 363.495039] schedule+0x32/0x80 [ 363.495042] io_schedule+0x12/0x40 [ 363.495045] __lock_page_or_retry+0x302/0x320 [ 363.495047] ? page_cache_tree_insert+0xa0/0xa0 [ 363.495051] do_swap_page+0x4ab/0x860 [ 363.495054] __handle_mm_fault+0x77b/0x10c0 [ 363.495056] handle_mm_fault+0xc6/0x1b0 [ 363.495059] __get_user_pages+0xf9/0x620 [ 363.495061] ? update_load_avg+0x5d6/0x6d0 [ 363.495064] get_user_pages_remote+0x137/0x1f0 [ 363.495067] async_pf_execute+0x62/0x180 [ 363.495071] process_one_work+0x184/0x380 [ 363.495073] worker_thread+0x4d/0x3c0 [ 363.495076] kthread+0xf5/0x130 [ 363.495078] ? process_one_work+0x380/0x380 [ 363.495080] ? kthread_create_worker_on_cpu+0x50/0x50 [ 363.495083] ? do_group_exit+0x3a/0xa0 [ 363.495086] ret_from_fork+0x1f/0x30 -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/26/2018 08:10 AM, Tino Lehnig wrote: A thing I could imagine is [0bcac06f27d75, skip swapcache for swapin of synchronous device] It was merged into v4.15. Could you check it by bisecting? Thanks, I will check that. So I get the same behavior as in v4.15-rc1 after this commit. All prior builds are fine. I have also tested all other 4.15 rc builds now and the symptoms are the same through rc8. KVM processes become unresponsive and I see kernel messages like the one below. This happens with and without the writeback feature being used. The bad page state bug appears very rarely in these versions and only when writeback is active. Starting with rc9, I only get the same bad page state bug as in all newer kernels. -- [ 363.494793] INFO: task kworker/4:2:498 blocked for more than 120 seconds. [ 363.494872] Not tainted 4.14.0-zram-pre-rc1 #17 [ 363.494943] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 363.495021] kworker/4:2 D0 498 2 0x8000 [ 363.495029] Workqueue: events async_pf_execute [ 363.495030] Call Trace: [ 363.495037] ? __schedule+0x3bc/0x830 [ 363.495039] schedule+0x32/0x80 [ 363.495042] io_schedule+0x12/0x40 [ 363.495045] __lock_page_or_retry+0x302/0x320 [ 363.495047] ? page_cache_tree_insert+0xa0/0xa0 [ 363.495051] do_swap_page+0x4ab/0x860 [ 363.495054] __handle_mm_fault+0x77b/0x10c0 [ 363.495056] handle_mm_fault+0xc6/0x1b0 [ 363.495059] __get_user_pages+0xf9/0x620 [ 363.495061] ? update_load_avg+0x5d6/0x6d0 [ 363.495064] get_user_pages_remote+0x137/0x1f0 [ 363.495067] async_pf_execute+0x62/0x180 [ 363.495071] process_one_work+0x184/0x380 [ 363.495073] worker_thread+0x4d/0x3c0 [ 363.495076] kthread+0xf5/0x130 [ 363.495078] ? process_one_work+0x380/0x380 [ 363.495080] ? kthread_create_worker_on_cpu+0x50/0x50 [ 363.495083] ? do_group_exit+0x3a/0xa0 [ 363.495086] ret_from_fork+0x1f/0x30 -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/26/2018 08:21 AM, Minchan Kim wrote: That means you could reproduce it without writeback feature? If so, it would be more reasoanble to check [0bcac06f27d75, skip swapcache for swapin of synchronous device] No, the bug only occurs with a backing device. The writeback feature is enabled in the default Ubuntu kernel configuration. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
On 07/26/2018 08:21 AM, Minchan Kim wrote: That means you could reproduce it without writeback feature? If so, it would be more reasoanble to check [0bcac06f27d75, skip swapcache for swapin of synchronous device] No, the bug only occurs with a backing device. The writeback feature is enabled in the default Ubuntu kernel configuration. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
Hi, On 07/26/2018 04:03 AM, Minchan Kim wrote: A thing I could imagine is [0bcac06f27d75, skip swapcache for swapin of synchronous device] It was merged into v4.15. Could you check it by bisecting? Thanks, I will check that. My operating system is a minimal install of Debian 9. I took the kernel configuration from the default Debian kernel and built my own kernel with "make oldconfig" leaving all settings at their defaults. The only thing I changed in the configuration was enabling the zram writeback feature. You mean you changed host kernel configuration? All my tests were done on bare-metal hardware with Xeon processors and lots of RAM. I encounter the bug quite quickly, but it still takes several GBs of swap usage. Below is my /proc/meminfo with enough KVM instances running (3 in my case) to trigger the bug on my test machine. Aha.. you did writeback feature into your bare-metal host machine and execute kvm with window images as a guest. So, PG_uptodate warning happens on host side, not guest? Right? Yes, I am only talking about the host kernel. Zram swap is set up on the host. I just used Windows guests to fill up the host RAM and force it into swap. I will also try to reproduce the problem on some different hardware next. Just to confirm, I was able to reproduce the problem on another machine running Ubuntu 18.04 with the Ubuntu stock kernel (4.15) and no modifications to the kernel configuration whatsoever. The host had 8 GB of RAM, 32 GB of swap with zram and a 32 GB SSD as backing device. I had to start only one Windows VM with "-m 32768" to trigger the bug. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
Hi, On 07/26/2018 04:03 AM, Minchan Kim wrote: A thing I could imagine is [0bcac06f27d75, skip swapcache for swapin of synchronous device] It was merged into v4.15. Could you check it by bisecting? Thanks, I will check that. My operating system is a minimal install of Debian 9. I took the kernel configuration from the default Debian kernel and built my own kernel with "make oldconfig" leaving all settings at their defaults. The only thing I changed in the configuration was enabling the zram writeback feature. You mean you changed host kernel configuration? All my tests were done on bare-metal hardware with Xeon processors and lots of RAM. I encounter the bug quite quickly, but it still takes several GBs of swap usage. Below is my /proc/meminfo with enough KVM instances running (3 in my case) to trigger the bug on my test machine. Aha.. you did writeback feature into your bare-metal host machine and execute kvm with window images as a guest. So, PG_uptodate warning happens on host side, not guest? Right? Yes, I am only talking about the host kernel. Zram swap is set up on the host. I just used Windows guests to fill up the host RAM and force it into swap. I will also try to reproduce the problem on some different hardware next. Just to confirm, I was able to reproduce the problem on another machine running Ubuntu 18.04 with the Ubuntu stock kernel (4.15) and no modifications to the kernel configuration whatsoever. The host had 8 GB of RAM, 32 GB of swap with zram and a 32 GB SSD as backing device. I had to start only one Windows VM with "-m 32768" to trigger the bug. -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
Hi, On 07/25/2018 03:21 PM, Minchan Kim wrote: It would be much helpful if you could check more versions with git-bisect. I started bisecting today, but my results are not conclusive yet. It is certain that the problem started with 4.15 though. I have not encountered the bug message in 4.15-rc1 so far, but the kvm processes always became unresponsive after hitting swap and could not be killed there. I saw the same behavior in rc2, rc3, and other builds in between, but the bad state bug would only trigger occasionally there. The behavior in 4.15.18 is the same as in newer kernels. I also want to reproduce it. Today, I downloaded one window iso and execute it as cdrom with my owned compiled kernel on KVM but I couldn't reproduce. I also tested some heavy swap workload(kernel build with multiple CPU on small memory) but I failed to reproduce, too. Please could you told me your method more detail? I found that running Windows in KVM really is the only reliable method, maybe because the zero pages are easily compressible. There is actually not a lot of disk utilization on the backing device when running this test. My operating system is a minimal install of Debian 9. I took the kernel configuration from the default Debian kernel and built my own kernel with "make oldconfig" leaving all settings at their defaults. The only thing I changed in the configuration was enabling the zram writeback feature. All my tests were done on bare-metal hardware with Xeon processors and lots of RAM. I encounter the bug quite quickly, but it still takes several GBs of swap usage. Below is my /proc/meminfo with enough KVM instances running (3 in my case) to trigger the bug on my test machine. I will also try to reproduce the problem on some different hardware next. -- MemTotal: 264033384 kB MemFree: 1232968 kB MemAvailable: 0 kB Buffers:1152 kB Cached: 5036 kB SwapCached:49200 kB Active: 249955744 kB Inactive:5096148 kB Active(anon): 249953396 kB Inactive(anon): 5093084 kB Active(file): 2348 kB Inactive(file): 3064 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 1073741820 kB SwapFree: 938603260 kB Dirty:68 kB Writeback: 0 kB AnonPages: 255007752 kB Mapped: 4708 kB Shmem: 1212 kB Slab: 88500 kB SReclaimable: 16096 kB SUnreclaim:72404 kB KernelStack:5040 kB PageTables: 765560 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:1205758512 kB Committed_AS: 403586176 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 254799872 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 75136 kB DirectMap2M:10295296 kB DirectMap1G:260046848 kB -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
Hi, On 07/25/2018 03:21 PM, Minchan Kim wrote: It would be much helpful if you could check more versions with git-bisect. I started bisecting today, but my results are not conclusive yet. It is certain that the problem started with 4.15 though. I have not encountered the bug message in 4.15-rc1 so far, but the kvm processes always became unresponsive after hitting swap and could not be killed there. I saw the same behavior in rc2, rc3, and other builds in between, but the bad state bug would only trigger occasionally there. The behavior in 4.15.18 is the same as in newer kernels. I also want to reproduce it. Today, I downloaded one window iso and execute it as cdrom with my owned compiled kernel on KVM but I couldn't reproduce. I also tested some heavy swap workload(kernel build with multiple CPU on small memory) but I failed to reproduce, too. Please could you told me your method more detail? I found that running Windows in KVM really is the only reliable method, maybe because the zero pages are easily compressible. There is actually not a lot of disk utilization on the backing device when running this test. My operating system is a minimal install of Debian 9. I took the kernel configuration from the default Debian kernel and built my own kernel with "make oldconfig" leaving all settings at their defaults. The only thing I changed in the configuration was enabling the zram writeback feature. All my tests were done on bare-metal hardware with Xeon processors and lots of RAM. I encounter the bug quite quickly, but it still takes several GBs of swap usage. Below is my /proc/meminfo with enough KVM instances running (3 in my case) to trigger the bug on my test machine. I will also try to reproduce the problem on some different hardware next. -- MemTotal: 264033384 kB MemFree: 1232968 kB MemAvailable: 0 kB Buffers:1152 kB Cached: 5036 kB SwapCached:49200 kB Active: 249955744 kB Inactive:5096148 kB Active(anon): 249953396 kB Inactive(anon): 5093084 kB Active(file): 2348 kB Inactive(file): 3064 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 1073741820 kB SwapFree: 938603260 kB Dirty:68 kB Writeback: 0 kB AnonPages: 255007752 kB Mapped: 4708 kB Shmem: 1212 kB Slab: 88500 kB SReclaimable: 16096 kB SUnreclaim:72404 kB KernelStack:5040 kB PageTables: 765560 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:1205758512 kB Committed_AS: 403586176 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 254799872 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 75136 kB DirectMap2M:10295296 kB DirectMap1G:260046848 kB -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017 [ 170.708346] Call Trace: [ 170.708354] dump_stack+0x5c/0x7b [ 170.708357] bad_page+0xba/0x120 [ 170.708360] get_page_from_freelist+0x1016/0x1250 [ 170.708364] __alloc_pages_nodemask+0xfa/0x250 [ 170.708368] alloc_pages_vma+0x7c/0x1c0 [ 170.708371] do_swap_page+0x347/0x920 [ 170.708375] ? do_huge_pmd_anonymous_page+0x461/0x6f0 [ 170.708377] __handle_mm_fault+0x7b4/0x1110 [ 170.708380] ? call_function_interrupt+0xa/0x20 [ 170.708383] handle_mm_fault+0xfc/0x1f0 [ 170.708385] __get_user_pages+0x12f/0x690 [ 170.708387] get_user_pages_unlocked+0x148/0x1f0 [ 170.708415] __gfn_to_pfn_memslot+0xff/0x3c0 [kvm] [ 170.708433] try_async_pf+0x87/0x230 [kvm] [ 170.708450] tdp_page_fault+0x132/0x290 [kvm] [ 170.708455] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708470] kvm_mmu_page_fault+0x74/0x570 [kvm] [ 170.708474] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708477] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708480] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708484] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708487] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708490] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708493] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708497] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708500] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708503] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708506] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708510] ? vmx_vcpu_run+0x375/0x620 [kvm_intel] [ 170.708526] kvm_arch_vcpu_ioctl_run+0x9b3/0x1990 [kvm] [ 170.708529] ? futex_wake+0x94/0x170 [ 170.708542] ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm] [ 170.708555] kvm_vcpu_ioctl+0x388/0x5d0 [kvm] [ 170.708558] ? __handle_mm_fault+0x7c4/0x1110 [ 170.708561] do_vfs_ioctl+0xa2/0x630 [ 170.708563] ? __x64_sys_futex+0x88/0x180 [ 170.708565] ksys_ioctl+0x70/0x80 [ 170.708568] ? exit_to_usermode_loop+0xca/0xf0 [ 170.708570] __x64_sys_ioctl+0x16/0x20 [ 170.708572] do_syscall_64+0x55/0x100 [ 170.708574] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 170.708577] RIP: 0033:0x7fc9e4889dd7 [ 170.708577] Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 80 2b 00 f7 d8 64 89 01 48 [ 170.708610] RSP: 002b:7fc9c27fb8b8 EFLAGS: 0246 ORIG_RAX: 0010 [ 170.708612] RAX: ffda RBX: ae80 RCX: 7fc9e4889dd7 [ 170.708613] RDX: RSI: ae80 RDI: 0015 [ 170.708614] RBP: 55dbb5f263e0 R08: 55dbb34f03d0 R09: [ 170.708616] R10: 7fc9c27fb670 R11: 0246 R12: [ 170.708617] R13: 7fc9e9ed5000 R14: R15: 55dbb5f263e0 [ 170.708618] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017 [ 170.708346] Call Trace: [ 170.708354] dump_stack+0x5c/0x7b [ 170.708357] bad_page+0xba/0x120 [ 170.708360] get_page_from_freelist+0x1016/0x1250 [ 170.708364] __alloc_pages_nodemask+0xfa/0x250 [ 170.708368] alloc_pages_vma+0x7c/0x1c0 [ 170.708371] do_swap_page+0x347/0x920 [ 170.708375] ? do_huge_pmd_anonymous_page+0x461/0x6f0 [ 170.708377] __handle_mm_fault+0x7b4/0x1110 [ 170.708380] ? call_function_interrupt+0xa/0x20 [ 170.708383] handle_mm_fault+0xfc/0x1f0 [ 170.708385] __get_user_pages+0x12f/0x690 [ 170.708387] get_user_pages_unlocked+0x148/0x1f0 [ 170.708415] __gfn_to_pfn_memslot+0xff/0x3c0 [kvm] [ 170.708433] try_async_pf+0x87/0x230 [kvm] [ 170.708450] tdp_page_fault+0x132/0x290 [kvm] [ 170.708455] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708470] kvm_mmu_page_fault+0x74/0x570 [kvm] [ 170.708474] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708477] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708480] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708484] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708487] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708490] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708493] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708497] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708500] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708503] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] [ 170.708506] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] [ 170.708510] ? vmx_vcpu_run+0x375/0x620 [kvm_intel] [ 170.708526] kvm_arch_vcpu_ioctl_run+0x9b3/0x1990 [kvm] [ 170.708529] ? futex_wake+0x94/0x170 [ 170.708542] ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm] [ 170.708555] kvm_vcpu_ioctl+0x388/0x5d0 [kvm] [ 170.708558] ? __handle_mm_fault+0x7c4/0x1110 [ 170.708561] do_vfs_ioctl+0xa2/0x630 [ 170.708563] ? __x64_sys_futex+0x88/0x180 [ 170.708565] ksys_ioctl+0x70/0x80 [ 170.708568] ? exit_to_usermode_loop+0xca/0xf0 [ 170.708570] __x64_sys_ioctl+0x16/0x20 [ 170.708572] do_syscall_64+0x55/0x100 [ 170.708574] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 170.708577] RIP: 0033:0x7fc9e4889dd7 [ 170.708577] Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 80 2b 00 f7 d8 64 89 01 48 [ 170.708610] RSP: 002b:7fc9c27fb8b8 EFLAGS: 0246 ORIG_RAX: 0010 [ 170.708612] RAX: ffda RBX: ae80 RCX: 7fc9e4889dd7 [ 170.708613] RDX: RSI: ae80 RDI: 0015 [ 170.708614] RBP: 55dbb5f263e0 R08: 55dbb34f03d0 R09: [ 170.708616] R10: 7fc9c27fb670 R11: 0246 R12: [ 170.708617] R13: 7fc9e9ed5000 R14: R15: 55dbb5f263e0 [ 170.708618] Disabling lock debugging due to kernel taint -- Kind regards, Tino Lehnig
Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
RSP: 002b:7fb2e97f98b8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: ae80 RCX: 7fb30361add7 RDX: RSI: ae80 RDI: 0015 RBP: 5652b984e0f0 R08: 5652b7d513d0 R09: 0001 R10: R11: 0246 R12: R13: 7fb308c66000 R14: R15: 5652b984e0f0 -- ver_linux: Debian 9.5 with Kernel 4.18.0-rc5+ GNU C 6.3.0 GNU Make4.1 Binutils2.28 Util-linux 2.29.2 Mount 2.29.2 Module-init-tools 23 E2fsprogs 1.43.4 Linux C Library 2.24 Dynamic linker (ldd)2.24 Linux C++ Library 6.0.22 Procps 3.3.12 Kbd 2.0.3 Console-tools 2.0.3 Sh-utils8.26 Udev232 -- cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz stepping: 1 microcode : 0xb21 cpu MHz : 1200.632 cache size : 25600 KB physical id : 0 siblings: 20 core id : 0 cpu cores : 10 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass bogomips: 4400.00 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: -- Kind regards, Tino Lehnig config-4.18.0-rc5+.gz Description: application/gzip
Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...
RSP: 002b:7fb2e97f98b8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: ae80 RCX: 7fb30361add7 RDX: RSI: ae80 RDI: 0015 RBP: 5652b984e0f0 R08: 5652b7d513d0 R09: 0001 R10: R11: 0246 R12: R13: 7fb308c66000 R14: R15: 5652b984e0f0 -- ver_linux: Debian 9.5 with Kernel 4.18.0-rc5+ GNU C 6.3.0 GNU Make4.1 Binutils2.28 Util-linux 2.29.2 Mount 2.29.2 Module-init-tools 23 E2fsprogs 1.43.4 Linux C Library 2.24 Dynamic linker (ldd)2.24 Linux C++ Library 6.0.22 Procps 3.3.12 Kbd 2.0.3 Console-tools 2.0.3 Sh-utils8.26 Udev232 -- cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz stepping: 1 microcode : 0xb21 cpu MHz : 1200.632 cache size : 25600 KB physical id : 0 siblings: 20 core id : 0 cpu cores : 10 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass bogomips: 4400.00 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: -- Kind regards, Tino Lehnig config-4.18.0-rc5+.gz Description: application/gzip
