Linux Scheduler Debugging

Question

I am trying to implement a new kernel planner as my academic project. I know that this can slow down the system, but for the purpose of debugging. I am writing a printk statement in a context and schedule switching function so that I can see the event in dmesg. But I do not get any result in the dmesg file. I tried to insert the printk statement in different places, but did not get any output. am i doing something? Is there a better tool or technique for debugging this task?

Answer 1

How about learning ftrace for the Linux kernel? Method of use - slightly dependent on the kernel version. Just read the file / sys / kernel / debug / tracing / README for details.

If the above directory is missing, you may need to install it:

mount -t debugfs nodev /sys/kernel/debug 

And then write a bash shell to create a user space trace:

 #!/bin/bash echo 0 >/sys/kernel/debug/tracing/tracing_enabled echo 'sched_*' 'irq_*' > /sys/kernel/debug/tracing/set_ftrace_filter echo function >/sys/kernel/debug/tracing/current_tracer echo 1 >/sys/kernel/debug/tracing/tracing_enabled ls -al /tmp/ 1>/dev/null & ls -al /tmp/ 1>/dev/null & ls -al /tmp/ 1>/dev/null & ls -al /tmp/ 1>/dev/null & ls -al /tmp/ 1>/dev/null & ls -al /tmp/ 1>/dev/null & sleep 3 echo 0 >/sys/kernel/debug/tracing/tracing_enabled cat /sys/kernel/debug/tracing/trace 

Notes:

a. Linux kernel planning is implemented in the kernel / directory schedule from the kernel source. For example, CFQ in fair.c.

b. Reading the files and looking for the API, we know that the corresponding API involved in the planning starts with "irq_" and "sched_", so we code it in the shell script above.

from. The output of the above shell script on my system is located below (it has gzipped, about 21K lines after a massive truncation of "open" related functions):

https://drive.google.com/file/d/0B1hg6_FvnEa8dDBMcl9tcEs2VEU/edit?usp=sharing

Basically, you can see which kernel function is involved in the process context. From the kernel function names, you can continue tracing by reading the source code.

You can find more information on Google, for example:

http://tthtlc.wordpress.com/2013/11/19/using-ftrace-to-understanding-linux-kernel-api/

Answer 2

Perhaps you need to raise the kernel log log level . Read which level is currently set:

 cat /proc/sys/kernel/printk 

This entry must be greater than DEFAULT_MESSAGE_LOGLEVEL defined in kernel/printk.c
You can change it to another value, for example 2 to:

 echo 2 > /proc/sys/kernel/printk 

If you do not want to change DEFAULT_MESSAGE_LOGLEVEL , then you can give flag a higher priority when calling printk , something like:

 printk(KERN_ERR "Hello world"); //or any higher priority flag 

For more information read on.