2

All we know that context switch time is pure overhead and is of no use.But i would like to know how can one reduced context switch time .Is using more register help us doing in so?

Amit Singh Tomar
  • 8,380
  • 27
  • 120
  • 199
  • I won't say that context switching is of no use. It is fundamental to implement any kind of "multi-tasked" system. Saying that the time taken by context switch is pure overhead is IMHO an excessive simplification; it is like saying that the time to do an addition is overhead. Any processing inside physical machines takes time.... And the number of usable registers is defined by the instruction set and the ABI conventions – Basile Starynkevitch Jan 15 '12 at 07:17
  • Valid Point @BasileStarynkevitch ,I should have been asked this question with more care. – Amit Singh Tomar Jan 15 '12 at 07:20
  • I'm voting to close because I don't know what "Is using more register help us doing in so? " means. – Mikhail May 13 '16 at 05:58
  • Nice [XY question](http://stackoverflow.com/questions/8868135/how-do-we-reduce-context-switch-time#comment11081651_8868147). I answered Y in my answer. – doug65536 May 13 '16 at 09:26

3 Answers3

1

Are you writing an operating system? The context switch time is dependent on the registers you have to save / restore. One way you can possibly save time is via the AVX extensions on new processors, which allow you to save/restore all of the registers to one block of memory.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • No I am not writing operating system .This ,I have been asked in an interview – Amit Singh Tomar Jan 15 '12 at 07:18
  • You cannot change the context switch time directly. The only way you can avoid spending time in context switches is to avoid allocating more active threads than CPUs, and by not blocking threads (i.e. via Sleep or critical sections) – Ana Betts Jan 15 '12 at 07:20
1

Minimize the context size and/or avoid context switches. How exactly yo do that depends on the context (not the context that you're switching but the context of the problem, the CPU, the OS, etc).

On the x86 CPU you can avoid unnecessary saving and restoring of the state of the floating point unit if it doesn't change. This is done by setting the task switched bit in CR0 to 1 during a context switch and then waiting for a special CPU exception originating from the first FPU instruction of the new thread. When it occurs, you save the old thread's FPU state, load the current thread's FPU state, reset CR0.TS and resume execution at that FPU instruction. If threads come and go but the exception doesn't occur, that means the threads aren't doing FPU work and you don't do full context switches.

Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • True, but on modern processors [they don't bother with TS flag](http://stackoverflow.com/questions/2711044/why-doesnt-linux-use-the-hardware-context-switch-via-the-tss) anymore. – doug65536 May 13 '16 at 09:23
0

It would be up to the programmer to implement a threading policy, synchronization mechanisms, and data structures that minimize lock contention. When a thread tries to acquire a lock that is already acquired by another thread, it has little choice but to poll several times, hoping they will release it within a very short time, then give up and do a context switch.

If this question was from the perspective of a linux administrator, you can reduce time spent in context switches by increasing the minimum timeslice (see sched_latency_ns and sched_min_granularity_ns), or by ensuring that the demand for processors is less than or equal to the number of available processors. Context switch rate is significantly lower when you have spare processors - it won't need to "switch" any existing processors, it can use an idle one.

doug65536
  • 6,562
  • 3
  • 43
  • 53
  • I answered [this](http://stackoverflow.com/questions/8868135/how-do-we-reduce-context-switch-time#comment11081651_8868147) – doug65536 May 13 '16 at 09:26