Timertop is a set containing a Linux kernel patch and a user space utility. They work together in order to show in a console the profile of kernel timers utilization. Its development was suggested by Tony Lindgren, one of the creators of the dyn-tick patch, which this tool depends.
The kernel patch inserts a hook in the function next_timer_interrupt (@kernel/timer.c) , a very important dyn-tick function. This hook is a function in the kernel/timertop.c file, account_timer, which retrieves the address of the timer function and some related data and accounts it in a list.
Besides inserting new entries on that list, the function counts the amount of times the timer has expired for that particular timer function and/or process.
The timer functions are all functions from kernel space that are programmed to run when some time (measured in timer ticks) expires.
Thus with Timertop kernel patch one can count how many times such a timer function has been called/expired and store this information so that can be used later.
When the userspace requests the reading of the /proc/top_info file system entry, this kernel list is exported to the console.
The Timertop usespace tool gets this former output and displays it in a interactive manner enabling the users to see the timers usage of kernel timers requested by kernel functions that can be requested or not by user space directly. Indeed they can be request by some other kernel part, indirectly from a userpace program or by kernel loaded modules.
Ok, that's nice. But why do I need it?
Besides showing all that timer information interactively on the screen, Timertop serves as a tool to optimize the idle periods of the machine. To explain this we need some understanding of the dyn-tick patch. The latter was developed in order to prevent the machine to wake up from idle state every time a timer tick interrupt occurs, 1000 times per second if you have a 1000HZ value in your kernel. Every time this interrupt occurs it checks if there is timers to run, run it if so, perform some other activities and goes to sleep again. Straightforward to imagine that not all times the processor wakes up there is useful job to do.
But that is very fast and we go to sleep again hastely, one can say.
Indeed but that depends on how deep was the sleepness of the processor in the idle mode. In idle mode one can go to deep powersave states in terms of inactivity of the processors taking more time to wake up due to latencies in the hardware sybsystems, thereby great amounts of transitions should be avoided as much as possible. Furthermore, this strong powersave mode could make your battery lasts more, so the more time you stay there the better.
With dyn-tick patch, the timer interrupt will wake up the processor only when there is job to do, not in vain, in other words only when some kernel timer will expire. Hence, the amount of times your system wake up to handle timer issues is not more dependent from a fixed HZ but from the amount of programmed timers and its expiration periods.
So it'd be a good idea to fine tune this periods and prevent the system to wake up unnecessarily. You can do that if you know which timers are running, their frequencies and their owners.
That's what Timertop is for.
Nenhum comentário:
Postar um comentário