0

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?

Johnny
  • 1,509
  • 5
  • 25
  • 38
  • Do you mean how long it takes the CPU from executing user code to execute kernel code? Or how often the scheduler switchs from one task to another? Or how much does it takes for the OS to suspend a task and rerun the next one in its running queue? – mcleod_ideafix Jan 01 '14 at 23:12
  • @mcleod_ideafix I mean absolutely the last one " how much does it takes for the OS to suspend a task and rerun the next one in its running queue?" because it is the effective time that the program sees! – Johnny Jan 01 '14 at 23:16
  • Is this box overloaded, ie. does it have more ready threads than cores? Is the new thread in a different process? How much cache has to be reloaded? If the box is quiet, same process and no cache-load, making another thread running by signaling it takes about 5-7 microseconds on my Vista box. Other common scenarios will take longer. – Martin James Jan 01 '14 at 23:21
  • @MartinJames So you mean there can be no such a code to do that and I only can use 10 microSeconds as a rule of thumb! – Johnny Jan 01 '14 at 23:24
  • 1
    Well, that is how long it takes for that scenario on my box - it's the only one I've timed. Threads made ready by a driver will obviously take longer 'cos the driver has to run its code first. Threads made running by preempting another thread running on a different core will take longer because of the inter-core hardware signaling. It all varies somewhat. – Martin James Jan 01 '14 at 23:31

3 Answers3

3

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.

nullptr
  • 11,008
  • 1
  • 23
  • 18
0

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.

bazza
  • 7,580
  • 15
  • 22
0

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.

user207421
  • 305,947
  • 44
  • 307
  • 483