RFC : Understanding components of the kernel

I plan to start a series of articles explaining the Linux Kernel code as I understand it. I plan to cover some core ideas and subsystems. I do not intend to compete with LWN or other professional writers.

My biggest challenge would be to find a good drawing tool and keeping the documentation up to date.

Analysis of the double wakeup problem in Linux

Some time back there was a discussion on lkml about mutex vs semaphores. Check out Goodbye Semaphores?. You might have to wait until 12 Jan 2006 to read it, if you do not have a LWN subscription.

The main reason Linus accepted Ingo's new patch is because semaphores did not perform as well as the new mutex code and of-course various other reasons. Linus and others quickly found the main cause of the performance hit to be the double wakeup problem.

If you are interested in this kind of stuff, I posted my analysis of the double wakeup issue on lkml. Here is the complete analysis

When the past comes back with a surprise

Long long ago, I had posted a patch to lkml for O(1) estimation of slab size estimation.

Here is the original email and the thread. This morning, I saw the following threads

1. slab.c:cache_estimate cleanup
2. [PATCH] micro optimization of cache_estimate in slab.c

In the latest thread, both myself and Steven Rostedt have posted our analysis to prove that the O(1) algorithm works. Interested? Check all the three emails and their threads.

As usual comments are welcome, this time clarifications too!

Confession of a software programmer

Software programmers are known to be lazy and famous for writing buggy code. Well, not all programmers, some do write wonderful stuff. So good that its a pleasure to read the code and execute their program.

I feel that I belong to the lazy and buggy code writers category. So, this year (this month) I have decided to write some code, that I should have written a long time back. I plan to write the code with the following goals in mind

1. Develop several test cases to prove that the code works
2. Track Quality of code
3. Keep track of every single mistake I make while writing it and time required to fix errors
4. Track the number of compilations, crashes, the number of times the source code is edited and time required for each action

You must wonder how I will do all this and still develop code. Well, I have a plan of action

Use Karm (KDE's time tracking tool) to track how my time on the computer is spent. I think it should be an interesting exercise if followed honestly.

Screenshot of Karm

New year advice (to myself)

Use a book (especially a technical one) as a guide.

Like a traveler would use a map to understand the city. The book being the map and the city being the subject. One cannot claim to have understood the city, by just having seen things on the map. It is critical to explore the city and use the map when lost or to reach some destination.

I understand that my blog has moved from being technical, but I hope to continue on the tech-mania this year.