#format wiki
#language en
== About Me ==
I am a Linux Kernel Developer working at IBM, Linux Technology Center, India. I work in the area of CPU Power Management, specifically enabling deep CPU Idle states and improving the CPU Frequency subsystem on IBM POWER platforms. I have been involved in the discussions around Power Aware Scheduling in the kernel community where we are trying to improve the power efficiency of the kernel. Of late I have been reviewing patches around Dynamic Ticks and am keenly interested in the Full Dynamic Ticks Infrastructure.

== Project Details ==
== References ==
 1. The chapter on "Time Management" at http://www.e-reading.link/bookreader.php/142109/Professional_Linux_kernel_architecture.pdf
 1. https://www.kernel.org/doc/Documentation/timers/NO_HZ.txt
 1. Status of Linux Dynamic Ticks: http://ertl.jp/~shinpei/conf/ospert13/slides/FredericWeisbecker.pdf

== Tasks ==
The following tasks are listed in the increasing order of complexity. 
== Please note that the same task can be claimed by more than one intern ==

To begin with, download the vanilla kernel.

== Challenge Problem 1 ==
Configure two different kernels, one with NO_HZ_IDLE=y and another with NO_HZ_IDLE=n. Boot each of these kernels and perform the following test on each.

Download the ebizzy benchmark from http://sourceforge.net/projects/ebizzy/. Compile and run this benchmark a few times. You must see consistent    results. Record the number of records read. Download the powertop utility and run it while running the benchmark. Record the %time spent in different idle states.

Now compare the records read and %time spent in different idle states in both the above kernels and conclude as to which of the two has a better power efficiency.

== Challenge Problem 2 ==


git://git.kernel.org/pub/scm/linux/kernel/git/frederic/dynticks-testing.git. Clone this archive.

Run this on two different kernels. The first kernel should be compiled with CONFIG_NO_HZ_IDLE = y in the config file and the second kernel compiled with  CONFIG_NO_HZ_FULL = y.


== Goal of the Project for the Internship Period ==

It is to improve Full Dynticks in general. Hence we are quite flexible
on the tasks to perform. Now some of them are easier to handle than the others.
But there is one task that could be a good start: _ struct timer_list affinity

struct timer_list timers are those timers that have a
CONFIG_HZ granularity. They are handled by the timer tick: every time the
tick fires, we check if we have expired timers from the queue of struct timer_list.
And if so, we execute them.

Some of these timers are pinned (they execute on a specific CPU only).
Some timers are not pinned, which means they can execute on any CPU).

This is what we call timer affinity. And this affinity is fine on most workloads.
Timers usually execute fast enough that we don't care much about them. But
Full Dynticks CPUs don't want to be disturbed by anything. Now if a non-pinned
timer decides to execute on a full dynticks CPU, the tick will fire on it in order
to run the timer.

In order to solve this, we would like to affine non-pinned timers to the CPUs
that aren't in full dynticks mode.

We are flexible about the timeline. This can be done during the whole OPW
internship timeline. Here is a tentative timeline though.

Week 1 : Understanding the tasks involved and clearing doubts by interacting with the community and mentors.

Week 2 - Week 8:  Major task for the project:
Improving on _ struct timer_list affinity to affine non-pinned timers to the CPUs that aren't in full dynticks mode. 

Week 9 : Backup week in case some tasks take more time than expected.

Week 10 :  Get review from mentors and community. Testing. Code refactoring.

Week 11 - Week 13 :  Extra tasks related to the project.

== Contact Info ==
You can email me at: preeti@linux.vnet.ibm.com

My IRC handle is preeti