Tuesday, September 30, 2008

You cannot do SMP in VMWare Player

VMWare player doesn't support SMP, though you might see a processor which is capable of SMP. Here is a quote from the VMWarePlayer manual:
Virtual SMP
VMware Player does not support Virtual SMP™. You cannot use VMware
virtual machine that has more than one virtual processor assigned.

For e.g. when I look at /proc/cpuinfo, I am seeing only one processor though my VMWare Player emulates "Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz". When I inspect the boot messages, I realized that my Linux switch to uniprocessor configuration while booting:
[ 7.135461] SMP alternatives: switching to UP code
[ 7.135523] Freeing SMP alternatives: 11k freed

So if you are trying to test any multithreaded appplication, beware that the results you will get in your VMWare Player's Linux and the real Linux will not be the same. Your VMWare Player's version is likely to give you worse results as its running in uniprocessor mode.

Global Interpreter Lock in Python

Recently we were having an interesting discussion in our team about the threading and performance in Python. One of the key concerns was the Global Interpreter Lock (GIL) in Python. GIL is acquired before any thread accesses any of the Python objects. So if you are writing any C extensions and if you would like to manipulate any Python object, you must first acquire the lock and then only you can read/write/modify any object. Due to this, you will always have considerable of your code sequential.

There is a lot of discussion about GIL on the web. You will particularly find this page useful.

Someone suggested that Lua, by design, doesn't have any such constraints. It performs very well when it comes to multithreading. As I don't have much experience in programming in Lua, I don't know if that claim is true or not.

I am also not sure if Perl has any such global locks issue. I tried to Google it, but didn't find anything useful.

A useful tool to print the signals status

I have written a useful tool that will help in analyzing the signal disposition for a given process. It will take the list of PIDs as input and will print the signal disposition of that process in a readable form. For e.g.
5877: SigQ: 0/4096
5877: SigPnd: None (mask 0000000000000000)
5877: SigBlk: None (mask 0000000000000000)
5877: SigIgn: SIGHUP, SIGUSR2, SIGWINCH, SIGIO (mask 0000000030001002)
5877: SigCgt: SIGALRM (mask 0000000000004001)

The first column is the PID and the second column is the disposition and the the third column is the list of signals in a readable form.

It is a Python script. You can download that from here.

By default, the script doesn't print the real-time signals. To force it, you can specify the -r option in the command line. Sometimes there are signals for which there is no name available (for e.g. Signal 0). If such is the case, it will simply say 'Signal X'. There is no option to print the signal status of all the threads under the given process ID. If you know the thread ID ("ps -Leaf"), you can specify that to get the relevant information.

You can get the help for this script using -h. I have tested it in my Ubuntu box running kernel 2.6.24. Please drop me a word if you feel I can improve anything.

Monday, September 29, 2008

Identifying threads under a given process

This is quick note. The method to identify all the threads under a given process ID differs significantly between Linux kernel versions 2.4.x and 2.6.x.

In case of 2.4.x kernel, you should look for process IDs that are prefixed with dot (".") under the /proc folder. All these PIDs correspond to threads. If you open the /proc/.X/status file , the number appearing against "Tgid:" is the PID of the process that this thread corresponds to. So there is no direct way to tell the list of all the threads undre a given PID. The only way you can get that list is to iterate through all the directories that begin with dot under /proc, and check the "Tgid:" to be matching the PID in question.

In case of 2.6.x kernel, all you need to do is just to get the list of all the directories under /proc/PID/task. Each one of these IDs will correspond to one thread of the process. Also you will exactly know how many threads are there by checking the "Threads:" value in the /proc/PID/status file.

Check if your ps supports the option "-L". If it is supported, you can use that to get better information about the threads under each process.

Monday, September 08, 2008

What is 3G anyway?

I must admit that I didn't know the difference between 2G and 3G wireless technologies until recently. Whenever a discussion comes up among our friends about 3G, everyone seemed to be offering some opinion but me. So I ventured into understanding what is 3G. I know that I don't need to delve deeper to debate about 3G, but to understand it from a layman's perspective. One of the pages that I found was helpful was RadioShack's comparison page that tabulates the difference between different generations. That was a good starting point, from where I went to Wiki to learn more about each generations. I found the following pages to be helpful: