How to deal with the xfs_vm_releasepage warning problem reported by the Linux system
|
Problem Description Several machines recently displayed the following warning messages at different times of the day: Mar 26 20:55:03 host1 kernel: WARNING: at fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs]() Mar 26 20:55:03 host1 kernel: Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables ebtable_filter ebtables ip6table_ filter ip6_tables devlink bridge stp llc xt_multiport sunrpc dm_mirror dm_region_hash dm_log dm_mod intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypa ss crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas ipmi_devintf ipmi_si sg pcspkr ipmi_msg handler shpchp i2c_i801 lpc_ich nfit libnvdimm acpi_power_meter kgwttm(OE) xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_i ntel mgag200 drm_kms_helper igb syscopyarea sysfillrect sysimgblt ptp fb_sys_fops ttm pps_core dca ahci drm i2c_algo_bit libahci megaraid_sas i2c_core libata Mar 26 20:55:03 host1 kernel: fjes [last unloaded: nf_defrag_ipv4] Mar 26 20:55:03 host1 kernel: CPU: 10 PID: 224 Comm: kswapd0 Tainted: G OE ------------ 3.10.0-514.21.2.el7.x86_64 #1 Mar 26 20:55:03 host1 kernel: Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 1.3.7 02/08/2018 Mar 26 20:55:03 host1 kernel: 000000000000000 00000000e02a0d05 ffff88103c7ebaa0 ffffffff81687073 Mar 26 20:55:03 host1 kernel: ffff88103c7ebad8 ffffffff81085cb0 ffffea0000687620 ffffea0000687600 Mar 26 20:55:03 host1 kernel: ffff88004a71daf8 ffff88103c7ebda0 ffffea0000687600 ffff88103c7ebae8 Mar 26 20:55:03 host1 kernel: Call Trace: Mar 26 20:55:03 host1 kernel: [<ffffffff81687073>] dump_stack+0x19/0x1b Mar 26 20:55:03 host1 kernel: [<ffffffff81085cb0>] warn_slowpath_common+0x70/0xb0 Mar 26 20:55:03 host1 kernel: [<ffffffff81085dfa>] warn_slowpath_null+0x1a/0x20 Mar 26 20:55:03 host1 kernel: [<ffffffffa038bfdb>] xfs_vm_releasepage+0xcb/0x100 [xfs] Mar 26 20:55:03 host1 kernel: [<ffffffff81180b22>] try_to_release_page+0x32/0x50 Mar 26 20:55:03 host1 kernel: [<ffffffff81196ad6>] shrink_active_list+0x3d6/0x3e0 Mar 26 20:55:03 host1 kernel: [<ffffffff81196ed1>] shrink_lruvec+0x3f1/0x770 Mar 26 20:55:03 host1 kernel: [<ffffffff811972c6>] shrink_zone+0x76/0x1a0 Mar 26 20:55:03 host1 kernel: [<ffffffff8119857c>] balance_pgdat+0x48c/0x5e0 Mar 26 20:55:03 host1 kernel: [<ffffffff81198843>] kswapd+0x173/0x450 Mar 26 20:55:03 host1 kernel: [<ffffffff810b1b20>] ? wake_up_atomic_t+0x30/0x30 Mar 26 20:55:03 host1 kernel: [<ffffffff811986d0>] ? balance_pgdat+0x5e0/0x5e0 Mar 26 20:55:03 host1 kernel: [<ffffffff810b0a4f>] kthread+0xcf/0xe0 Mar 26 20:55:03 host1 kernel: [<ffffffff810b0980>] ? kthread_create_on_node+0x140/0x140 Mar 26 20:55:03 host1 kernel: [<ffffffff81697698>] ret_from_fork+0x58/0x90 Mar 26 20:55:03 host1 kernel: [<ffffffff810b0980>] ? kthread_create_on_node+0x140/0x140 Mar 26 20:55:03 host1 kernel: ---[ end trace 24823c5c7a1ea2be ]--- The kernel and application crash information of these machines is taken over by the abrtd service. You can view the summary information through abrt-cli: # abrt-cli list --since 1547518209 id 2181dce8f72761585cb6a904dbff1806c1315c27 reason: WARNING: at fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs]() time: Sat 23 Mar 2019 08:30:45 PM CST cmdline: BOOT_IMAGE=/boot/vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/sda1 ro crashkernel=auto net.ifnames=0 biosdevname=0 package: kernel uid: 0 (root) count: 1 Directory: /var/spool/abrt/oops-2019-03-23-20:30:45-163925-0 The kernel versions are as follows:
Analytical Processing Red Hat Knowledge Base Refer to the Red Hat Knowledgebase document. This type of xfs warning message will be printed when the xfs module traverses the code path, which does not affect the host use. You can upgrade the kernel to kernel-3.10.0-693.el7 to avoid this warning message. For details, see: redhat-access-2893711
Code Analysis The Red Hat Knowledge Base does not mention any information about memory recycling, but judging from the stack information, it seems to be caused by the kernel recycling memory. The memory usage at the corresponding time point is as follows: 04:30:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty ...... 08:40:01 PM 513940 130976220 99.61 876 104616380 28610584 21.76 92439660 34840920 524 08:50:01 PM 479896 131010264 99.64 876 104666496 28557292 21.72 92513872 34804240 400 09:00:01 PM 455948 131034212 99.65 876 104675712 28588852 21.74 92418724 34926132 572 09:10:01 PM 556980 130933180 99.58 876 104610352 28552656 21.71 94287212 32983892 900 # sysctl vm.min_free_kbytes vm.min_free_kbytes = 90112 The available memory did not increase between 20:50 and 21:00, which means that the system may not have performed memory recovery operations. We can see the function call relationship according to the stack information of the kernel log:
shrink_active_list -> try_to_release_page -> xfs_vm_releasepage
//source/mm/filemap.c
3225 int try_to_release_page(struct page *page, gfp_t gfp_mask)
3226 {
3227 struct address_space * const mapping = page->mapping;
......
3233 if (mapping && mapping->a_ops->releasepage)
3234 return mapping->a_ops->releasepage(page, gfp_mask); xfs_vm_releasepage
3235 return try_to_free_buffers(page);
3236 }
//source/fs/xfs/xfs_aops.c
1034 STATIC int
1035 xfs_vm_releasepage(
1036 struct page *page,
1037 gfp_t gfp_mask)
1038 {
1039 int delalloc, unwritten;
1040
1041 trace_xfs_releasepage(page->mapping->host, page, 0, 0);
1042
1043 xfs_count_page_state(page, &delalloc, &unwritten);
1044
1045 if (WARN_ON_ONCE(delalloc))
1046 return 0;
1047 if (WARN_ON_ONCE(unwritten))
1048 return 0;
1049
1050 return try_to_free_buffers(page);
1051 }
......
1827 const struct address_space_operations xfs_address_space_operations = {
1833 .releasepage = xfs_vm_releasepage,Corresponding to the kernel log kernel: WARNING: at fs/xfs/xfs_aops.c:1045, it can be seen that the stack information is printed in line 1045 of the source file source/fs/xfs/xfs_aops.c. In fact, try_to_free_buffers is not executed and it has already returned: 1045 if (WARN_ON_ONCE(delalloc)) 1046 return 0; WARN_ON_ONCE is relatively simple and can be found in the source file source/include/asm-generic/bug.h:
73 #define __WARN() warn_slowpath_null(__FILE__, __LINE__)
85 #define WARN_ON(condition) ({ \
...
88 __WARN(); \
136 #define WARN_ON_ONCE(condition) ({ \
....
140 if (unlikely(__ret_warn_once)) \
141 if (WARN_ON(!__warned)) \The __WARN function calls the warn_slowpath_null function in the stack information, and then calls the warn_slowpath_common function to print the stack information:
//source/kernel/panic.c
517 void warn_slowpath_null(const char *file, int line)
518 {
519 warn_slowpath_common(file, line, __builtin_return_address(0),
520 TAINT_WARN, NULL);
521 }
463 static void warn_slowpath_common(const char *file, int line, void *caller,
464 unsigned taint, struct slowpath_args *args)
465 {
466 disable_trace_on_warning();
467
468 printk(KERN_WARNING "------------[ cut here ]------------\n");
469 printk(KERN_WARNING "WARNING: at %s:%d %pS()\n", file, line, caller);
470
471 if (args)
472 vprintk(args->fmt, args->args);
......
485 print_modules();
486 dump_stack();
487 print_oops_end_marker();We can roughly see that this stack message is just a warning, consistent with the description in the Red Hat Knowledge Base, and does not affect the use of the host. Summary From the functions in the source file above, it is possible to print stack information as long as xfs_vm_releasepage is called when kswapd reclaims memory. If the stack is printed, the try_to_free_buffers operation will not be executed, so the available memory does not increase when checking memory usage. If you do not want the stack information to appear, you can turn off the stack prompt by turning on the kernel.traceoff_on_warning kernel parameter corresponding to the disable_trace_on_warning function. However, other kernel information will no longer be printed after turning it off. So from this point of view, only upgrading the kernel version can avoid this information. Well, that’s all for this article. I hope the content of this article will be of certain reference value to your study or work. Thank you for your support of 123WORDPRESS.COM. You may also be interested in:
|
<<: Mysql sorting to get ranking example code
>>: Detailed explanation of the difference between $router and $route in Vue
Recommend
How to implement real-time polygon refraction with threejs
Table of contents Preface Step 1: Setup and front...
HTML+CSS to create heartbeat special effects
Today we are going to create a simple heartbeat e...
Comprehensive understanding of html.css overflow
Comprehensive understanding of html.css overflow ...
Detailed explanation of how to use amoeba to implement read-write separation of MySQL database
There are many read-write separation architecture...
Docker image access to local elasticsearch port operation
Using the image service deployed by docker stack,...
WeChat applet implements simple calculator function
This article shares the specific code for the WeC...
Introduction to Linux system swap space
Swap space is a common aspect of computing today,...
MySQL 8.x msi version installation tutorial with pictures and text
1. Download MySQL Official website download addre...
How to use macros in JavaScript
In languages, macros are often used to implement ...
Using Openlayer in Vue to realize loading animation effect
Note: You cannot use scoped animations! ! ! ! via...
Differences between MySQL MyISAM and InnoDB
the difference: 1. InnoDB supports transactions, ...
Detailed process of upgrading gcc (version 10.2.0) under CentOS7 environment
Table of contents Short Introduction 1. Check the...
Don't forget to close the HTML tag
Building web pages that comply with Web standards ...
MySQL uses covering index to avoid table return and optimize query
Preface Before talking about covering index, we m...
7 skills that great graphic designers need to master
1》Be good at web design 2》Know how to design web p...