How can I discover how long does it take to do a context switch on my operating system?

Question

I'd like to know how long does it take a context switch on my operating system. Is there a hack to do this? Can I do it with Java or I will need native code (eg. in C)? Does context switch differ for different threads?

Answer 1

From user-space processes, you can get a rough estimate running several threads/processes each of them getting wall-time clock (or processor ticks, RTDSC) as frequently as it's possible for some significant amount of time, and then finding a minimal discrepancy between the measurements of different threads. And make sure they are running at the same core.

Another estimate can be obtained by using some kind of waiting on mutex or conditional variable, but that would rather show performance of thread/process wake-up.

In Java you may get an additional overhead for JVM.

I guess the only reliable way is to profile your kernel or maybe find the numbers in kernel documentation.

Probably before trying all that you should make sure why you need to know such a thing. Performance of a multi-threaded/multi-process application depends on many factors, and context switching is most often the minor one.

Answer 2

It's easy to write a bit if code to measure it. It's worth writing one yourself because you'll then get an answer relevant to your choice of language, etc. You should be able to write such a thing in any language that does threads and semaphores.

You need two threads or two processes. Have one of them record a high precision time of day (these days it will need to be good to nanoseconds, and that might be quite difficult. It will depend on the what the hardware/OS/language provides) in a shared buffer and then posts a semaphore. Your other thread or process should be written to be waiting on that semaphore. When it gets it it should then record the high precision time of day too, and subtract the time that the other thread/process had put in the shared buffer.

The reason why you might want to measure the context switch time for threads and processes is that a thread context switch time in a lot of OSes is less than that for processes (that's certainly true for Windows).

You could refine the answer with repeated runs and measure an average time. You could also similarly measure the time taken to post and take a semaphore to remove that component from the context switch time. I wouldn't bother with that because if you're worrying about the effect of context switch times you probably also care about the time taken to cause a context switch (such as posting a semaphore) as well.

I don't really know what results to expect these days. I know that VxWorks was achieving 10us context switch times on 200MHz PowerPC chips back in the 1990's, and that was really fast in those days.

==EDIT==

Context switching in multi core machines is potentially a much more variable thing. In a single core machine the OS must always switch execution contexts every time a different thread is to be run. But on a multi core machine the OS can distribute threads across cores, so there's not necessarily the need to do all the memory transactions associated with a context switch (I don't actually know if any OS out there does that). But given that thread / core distribution is itself a very variable thing depending on machine workload, etc, one's application might experience wildly variable CST depending on whether the user is moving the mouse, etc etc.

Answer 3

Just call sleep(0) a large number of times; observe the total elapsed time; and divide. Do this in a high-priority process so that it is always the next process to be scheduled itself.