CODEWITHSUNDEEP
assemblyoperating-systemscheduler
Celeritas
Celeritas

Reputation: 15043

What is the overhead associated with context switching?

In class we were learning about the different algorithms used in scheduling, for example preemption. Someone asked if the over head in switching context is a concern and the prof said it's always negligible. Is this true? According to wikipedia when a context switch happens the "state of the process includes all the registers that the process may be using, ... plus any other operating system specific data that may be necessary" so basically everything needs to be saved to memory which I wouldn't think is a negligible?

Are there any algorithms/implementations that would take into account the time it takes for the context switch? For example a task of 10ms is running but a new task that would take 8ms comes into the queue, would the scheduler ever say "forget it" because the extra context switch back to the 10ms one wouldn't be worth it?

Upvotes: 0

Views: 1415

Answers (1)

Martin James
Martin James

Reputation: 24857

Not negligible, but not much either. User registers, sure, maybe more segment/protection registers if a process change happnes as well as a thread change. The thread stack is already in memory and does not need saving. In the case of a thread made ready on I/O, the actual context-change is probably swamped by the running of the driver code.

10/8ms...

Most context-switches within a process are much quicker than that! In the case of threads within a process, we're talking often low uS, with possibly more overhead once the new thread runs if there is some cache-flushing to be done. There will be more overhead if the newly-running thread belongs to a different process - more registers to save and more likely cache etc. There will be yet more overhead is the context-switch involves stopping a thread on another core than that running the sheduler/dispatcher because the other core wil need to be interrupted.

Worst case - all the above plus an immediate page-fault because the new thread has not run for so long that it's code/stack/whatever has been paged out. Luckily, hardly ever happens.

If that 8ms thread was the high-priority rendering thread in your video-streaming app, you would not want it delayed, causing jitter, because of the OS scheduling algorithm screwing you over for the sake of some possible extra overhead:)

Upvotes: 1

Related Questions