How to check if a specific kernel slab setting is active in Linux

Introduction

In this lab, you will learn how to check if a specific kernel slab setting is active in Linux. You will explore different methods to inspect the kernel's memory management, specifically focusing on the slab allocator.

The lab will guide you through checking slab statistics using /proc/slabinfo, verifying related settings with sysctl vm, and inspecting relevant logs in dmesg. These steps will provide you with the necessary skills to understand and troubleshoot kernel slab behavior.

Skills Graph

Check slab stats with cat /proc/slabinfo

In this step, you will learn how to inspect the kernel's slab allocator statistics using the /proc/slabinfo file. The slab allocator is a memory management mechanism used by the Linux kernel to efficiently manage small objects. Understanding slab usage can be helpful for diagnosing memory-related issues.

The /proc filesystem is a virtual filesystem that provides information about processes and other system information. /proc/slabinfo specifically contains details about the kernel's slab caches.

To view the contents of /proc/slabinfo, you will use the cat command. cat is a standard Unix utility that reads files sequentially and writes them to standard output.

Open your terminal if it's not already open. You can do this by clicking the Xfce Terminal icon on the left side of the desktop.

Now, type the following command and press Enter:

cat /proc/slabinfo

You will see output similar to this (the exact content will vary depending on the system's activity):

slabinfo - version: 2.1
## name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_expect      0      0    128   63    1 : tunables    0    0    0 : slabdata      0      0      0
nf_conntrack      10     10    320   25    2 : tunables    0    0    0 : slabdata      1      1      0
request_sock_TCP      0      0    192   42    1 : tunables    0    0    0 : slabdata      0      0      0
... (many more lines)

Let's break down the output:

• name: The name of the slab cache (e.g., nf_conntrack, request_sock_TCP).
• <active_objs>: The number of objects currently in use in this cache.
• <num_objs>: The total number of objects allocated in this cache.
• : The size of each object in bytes.
• : The number of objects that fit into a single slab.
• : The number of memory pages used by a single slab.
• tunables: Parameters that can be tuned for this cache.
• slabdata: Information about the slabs themselves.

This output provides a snapshot of how the kernel is using memory for various internal data structures. While the raw output can be extensive, it's a fundamental source of information for advanced Linux troubleshooting.

You have successfully viewed the slab allocator statistics. Click Continue to proceed to the next step.

Verify slab settings with sysctl vm

In this step, you will explore kernel parameters related to virtual memory and the slab allocator using the sysctl command. sysctl is a utility that allows you to view and modify kernel parameters at runtime.

Kernel parameters are configuration options that affect the behavior of the Linux kernel. Many of these parameters are located in the /proc/sys filesystem. sysctl provides a convenient way to access and manage these parameters without directly interacting with the files in /proc/sys.

We are interested in parameters related to virtual memory, which often include settings that influence memory management, including aspects of the slab allocator. These parameters are typically grouped under the vm subtree.

To view all kernel parameters related to virtual memory, use the sysctl command with the vm argument:

sysctl vm

Type the command in your terminal and press Enter. You will see a list of parameters and their current values, similar to this:

vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.compact_memory = 0
vm.compact_unevictable_percentage = 1
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirtytime_expire_seconds = 43200
vm.drop_caches = 0
vm.extfrag_threshold = 500
vm.highmem_is_dirtyable = 0
vm.laptop_mode = 0
vm.lowmem_reserve_ratio = 256   256     32      0       0
vm.max_map_count = 65530
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 65536
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.numa_balancing = 1
vm.numa_balancing_scan_delay_ms = 1000
vm.numa_balancing_scan_period_min_ms = 20
vm.numa_balancing_scan_period_max_ms = 10000
vm.numa_balancing_scan_size_mb = 32
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 60
vm.user_reserve_kbytes = 131072
vm.vfs_cache_pressure = 100

Look for parameters that might be related to caching or memory pressure, such as vm.vfs_cache_pressure or vm.min_slab_ratio. These parameters can influence how the kernel manages different types of caches, including slab caches.

You can also view a specific parameter by providing its full name. For example, to see the value of vm.vfs_cache_pressure:

sysctl vm.vfs_cache_pressure

This command will output:

vm.vfs_cache_pressure = 100

The vm.vfs_cache_pressure parameter controls the tendency of the kernel to reclaim memory used for caching directory and inode objects. A higher value means the kernel is more aggressive in reclaiming this memory.

Understanding these parameters can help you tune your system's memory behavior.

Click Continue to move to the next step.

Inspect slab logs in dmesg

In this final step, you will learn how to check the kernel message buffer for messages related to the slab allocator using the dmesg command. The kernel message buffer stores messages produced by the kernel during boot and runtime. These messages can include information about hardware, device drivers, and kernel subsystems like the slab allocator.

The dmesg command is used to print or control the kernel ring buffer. This buffer contains messages from the kernel, which are often useful for debugging and troubleshooting.

To view the entire kernel message buffer, you can simply run dmesg:

dmesg

However, the output can be very long. To find messages specifically related to the slab allocator, you can pipe the output of dmesg to the grep command and search for keywords like "slab" or "SLUB" (SLUB is a modern slab allocator implementation).

Type the following command in your terminal and press Enter:

dmesg | grep -i "slab\|slub"

Let's break down this command:

• dmesg: Prints the kernel message buffer.
• |: This is a pipe, which sends the output of the command on the left as input to the command on the right.
• grep: A command-line utility for searching plain-text data sets for lines that match a regular expression.
• -i: This option makes the search case-insensitive, so it will match "slab", "SLAB", "slub", "SLUB", etc.
• "slab\|slub": This is the search pattern. slab searches for the word "slab", \| acts as an OR operator, and slub searches for the word "slub".

The output will show any lines from the kernel message buffer that contain "slab" or "slub" (case-insensitive). You might see messages related to the initialization of the slab allocator during boot, or potential warnings or errors if there are issues.

[    0.000000] kmem_cache_init
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] SLUB: TotalObjects=0, ObjectsPerSpan=0, SpansPerChunk=0
[    0.000000] SLUB: min_objects.limit=0, min_objects.batchcount=0
[    0.000000] SLUB: tunables.limit=0, tunables.batchcount=0, tunables.sharedfactor=0
[    0.000000] SLUB: Not setting slab_nomerge.
[    0.000000] SLUB: Not setting slab_debug.
[    0.000000] SLUB: Not setting slab_max_order.
[    0.000000] SLUB: Not setting slab_alias_debug.
[    0.000000] SLUB: Not setting slab_pad.
[    0.000000] SLUB: Not setting slab_red_zone.
[    0.000000] SLUB: Not setting slab_poison.
[    0.000000] SLUB: Not setting slab_freelist_debug.
[    0.000000] SLUB: Not setting slab_freelist_random.
[    0.000000] SLUB: Not setting slab_freelist_hardened.
[    0.000000] SLUB: Not setting slab_trace.
[    0.000000] SLUB: Not setting slab_reclaim_account.
[    0.000000] SLUB: Not setting slab_way.
[    0.000000] SLUB: Not setting slab_sizes.
[    0.000000] SLUB: Not setting slab_caches.
[    0.000000] SLUB: Not setting slab_test.
[    0.000000] SLUB: Not setting slab_order.
[    0.000000] SLUB: Not setting slab_debug_objects.
[    0.000000] SLUB: Not setting slab_debug_memcg.
[    0.000000] SLUB: Not setting slab_debug_check_objects.
[    0.000000] SLUB: Not setting slab_debug_check_freelist.
[    0.000000] SLUB: Not setting slab_debug_check_alloc.
[    0.000000] SLUB: Not setting slab_debug_check_free.
[    0.000000] SLUB: Not setting slab_debug_check_redzone.
[    0.000000] SLUB: Not setting slab_debug_check_poison.
[    0.000000] SLUB: Not setting slab_debug_check_trace.
[    0.000000] SLUB: Not setting slab_debug_check_reclaim_account.
[    0.000000] SLUB: Not setting slab_debug_check_way.
[    0.000000] SLUB: Not setting slab_debug_check_sizes.
[    0.000000] SLUB: Not setting slab_debug_check_caches.
[    0.000000] SLUB: Not setting slab_debug_check_test.
[    0.000000] SLUB: Not setting slab_debug_check_order.
[    0.000000] SLUB: Not setting slab_debug_check_debug_objects.
[    0.000000] SLUB: Not setting slab_debug_check_debug_memcg.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_objects.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_freelist.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_alloc.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_free.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_redzone.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_poison.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_trace.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_reclaim_account.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_way.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_sizes.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_caches.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_test.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_order.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_debug_objects.
[    0.000000] SLUB: Not setting slab_debug_check_debug_check_debug_memcg.

This command is a powerful way to filter kernel messages and find relevant information for troubleshooting specific kernel subsystems.

You have now learned how to inspect slab statistics, verify related kernel parameters, and check kernel logs for slab-related messages. These are fundamental skills for understanding and diagnosing memory usage in Linux.

Click Continue to complete this lab.

Summary

In this lab, you learned how to check kernel slab settings in Linux. You began by inspecting the kernel's slab allocator statistics using the /proc/slabinfo file, which provides details about active objects, total objects, object size, and other relevant information for various slab caches. This step demonstrated how to use the cat command to view this crucial memory management data.

Next, you verified slab settings using the sysctl vm command, which allows you to examine and modify kernel parameters related to virtual memory, including slab-specific tunables. Finally, you learned how to inspect slab-related logs in dmesg, the kernel message buffer, to identify any errors or warnings related to the slab allocator. These steps collectively provide a comprehensive approach to understanding and troubleshooting kernel slab behavior.