Linux系统状态信息维护机制及相关技术问题咨询
Great questions about the sysinfo struct—let's break this down clearly, since it's a key interface for fetching system state in Linux:
How does Linux maintain the information used by sysinfo?
Linux kernel subsystems track this data in real time across different components:
- Memory-related fields (like
totalram,freeram) are managed by the memory management module, updating counts as pages are allocated or freed. - Uptime and idle time are maintained by the clock subsystem, incrementing counters on each system tick.
- Process count (
procs) is tracked by the process scheduler, updating whenever a process is created (fork()) or destroyed (exit()). - Disk I/O stats come from the block layer, which monitors device activity continuously.
All these raw data points live in kernel-internal data structures, not a single dedicated struct—sysinfo() just aggregates them when called.
How is the sysinfo struct initialized?
The struct itself is a user-space definition from <sys/sysinfo.h>. Initialization happens on-demand when you call the sysinfo() system call:
- Declare an instance in your code:
struct sysinfo info; - When you invoke
sysinfo(&info);, the kernel collects the latest data from its internal subsystems, fills each field of the struct in your user-space memory, and returns control to your program.
It’s not pre-initialized somewhere; it’s a snapshot generated specifically for your call.
When is it created and how is it stored?
- Creation: The struct type is defined by the C library (glibc, musl, etc.) in
<sys/sysinfo.h>. A concrete instance is created when you declare it in your user-space program. - Storage: The filled struct lives in your program’s user-space memory. The kernel doesn’t store a persistent
sysinfoinstance—each call tosysinfo()generates a new snapshot and copies it to your program’s memory.
How is the information updated?
There’s no "updating the sysinfo struct" per se. Each time you call sysinfo(), you get a fresh snapshot of the current system state. The kernel’s internal subsystems are constantly updating their raw data (e.g., memory counts change every time an allocation happens, uptime ticks forward every millisecond), so each call pulls the latest values.
Can we customize the sysinfo struct?
No, you can’t modify the official sysinfo struct definition. It’s part of the Linux ABI (Application Binary Interface)—a fixed contract between the kernel and user-space programs. If you redefine the struct with different fields or sizes, the kernel will still write data using the original layout, leading to corrupted values or crashes.
That said, you can create your own custom struct in user space, copy the data from the sysinfo snapshot into it, and add any extra fields you need for your application.
Is there a file that stores this information?
Yes—Linux exposes this data (and much more) via the proc filesystem, a virtual filesystem that provides text-based access to kernel state. Relevant files include:
/proc/uptime: Contains system uptime and idle time/proc/meminfo: Detailed memory statistics (total RAM, free RAM, cached memory, etc.)/proc/loadavg: System load averages and process counts/proc/stat: Overall system statistics (CPU usage, disk I/O, etc.)
The sysinfo() system call uses the same kernel-internal data sources as these proc files—it just packages the data into a binary struct instead of text.
Are there alternative ways to get system state information?
Absolutely. Here are common alternatives:
- Other system calls:
getloadavg()for load averages,sysconf()for system configuration (e.g., page size),getrusage()for process-specific resource usage. - Library functions: The
procps-nglibrary (often packaged aslibprocps) provides helper functions to parse proc files easily, with more detailed data thansysinfo(). - Direct proc file parsing: Reading and parsing the text files in
/procgives you access to granular, detailed system stats thatsysinfo()doesn’t expose (like per-process memory usage, CPU core stats).
Can we bypass the sysinfo struct to get state information directly from hardware?
In theory, yes—but it's highly discouraged for most use cases, as it's complex, unsafe, and non-portable:
- Kernel-space approach: You'd need to write a kernel module that directly reads hardware registers (e.g., memory controller registers for RAM stats, CPU performance counters). This requires deep hardware knowledge and can destabilize the system if done incorrectly.
- User-space approach: With root privileges, you can use
ioperm()oriopl()to gain access to hardware I/O ports, but this only works for legacy hardware and is not portable across different architectures or devices.
A far better alternative is to use kernel-provided interfaces like the perf subsystem (for hardware performance counters) or the sysfs filesystem (/sys/class/) for hardware-specific state—these are safe, portable, and abstract the hardware details for you.
内容的提问来源于stack exchange,提问作者Rahul

