What is the most efficient way to track the number of context switches in a linux kernel?

I would like to get complete statistics about the following:

  • How many softirq happened?
  • How many interrupts happened?
  • How many context switches happened?

I know that you can use pidstat , cat /proc/interrupts and /cat/proc/softirqs . But using them is too much overhead.

  • How can I get the bottom line values ​​for {1-3} without working with /proc and in the fastest way?

  • Can ftrace be used to help me track events?

I am going to use high resolution timers to monitor the system:

+6
source share
4 answers

Check the Linux primary subsystem , so you need the performance of the counters to be soft or hard from the Linux system.

+5
source

Use perf , for example:

 # perf stat -B dd if=/dev/zero of=/dev/null count=1000000 1000000+0 records in 1000000+0 records out 512000000 bytes (512 MB) copied, 0.956217 s, 535 MB/s Performance counter stats for 'dd if=/dev/zero of=/dev/null count=1000000': 5,099 cache-misses # 0.005 M/sec (scaled from 66.58%) 235,384 cache-references # 0.246 M/sec (scaled from 66.56%) 9,281,660 branch-misses # 3.858 % (scaled from 33.50%) 240,609,766 branches # 251.559 M/sec (scaled from 33.66%) 1,403,561,257 instructions # 0.679 IPC (scaled from 50.23%) 2,066,201,729 cycles # 2160.227 M/sec (scaled from 66.67%) 217 page-faults # 0.000 M/sec 3 CPU-migrations # 0.000 M/sec 83 context-switches # 0.000 M/sec 956.474238 task-clock-msecs # 0.999 CPUs 0.957617512 seconds time elapsed 
+6
source

Perhaps you should consider writing a Linux kernel module (LKM).

There is a tutorial here: http://www.tldp.org/LDP/lkmpg/2.6/html/

If you need an accurate profiling system, you can attach your kernel module to some interrupt or any other valid entry point * and save (with a few instructions!) What you need for your account. Then, after the interruption, periodically collect and analyze this data.

You can export information in the same way as other modules do, through a special file in the file system (created in user space via mknode or inside initialization using MKDEV / register_chrdev).

There is some information in the link provided.

* For example, you can attach your module to syscall reading (wrap the actual reading from yours) or export the file and catch attempts to open / close.

An example of using a later version will look something like this:

 void f() { int fd_prof; fd_prof = open("/dev/profiler", O_RDONLY); /* Do whichever thing you want to profile */ close(fd_prof); /* Read profiled data from /dev/profiled_data or wherever you want * to export it to */ 

Please remember that when compiling LKM, you do not have access to the standard C library, since libc does not exist in kernel space.

Don’t worry, you will still have functions like sprintf implemented in kernel space, and of course you have direct access (without context switches) to any syscall (read, write ...)

+2
source

You can get all this information from /proc with some level of permission, and if you need more rez, you can configure the kernel of the embedded system.

The information you want can be tracked using $ vmstat 1 , and you can check the source on vmstat to see exactly how they read it from /proc in <code> http: //procps.sourceforge.net.code>

+2
source

All Articles