An OS without context switching

[Chandra]

However, IMO the biggest penalty of context-switch is a TLB flush, so saving/restoring even large registers
is not a bottleneck here.

Good point. Another reason to use cooperative multitasking.

Cooperative multitasking is the worst possible approach. You shouldn't be even considering it.

[Combuster]

Good point. Another reason to use cooperative multitasking.

Cooperative multitasking does nothing of its own to stop context switches, it only makes them happen at points a program finds "appropriate", and therefore does not serve your intended goal.

[rdos]

However, IMO the biggest penalty of context-switch is a TLB flush, so saving/restoring even large registers
is not a bottleneck here.

Good point. Another reason to use cooperative multitasking.

Cooperative multitasking is the worst possible approach. You shouldn't be even considering it.

Cooperative multitasking is a special case. It is a preemptive multitasking system without synchronization primitives and locking, and without a method in the OS to stop tasks from being uncooperative. Thus, programs written for cooperative multitasking work just fine on OSes with preemptive multitasking, while programs written for preemptive multitasking will not work on an OS that uses cooperative multitasking.

People that build OSes or programs for cooperative multitasking usually do this either because they don't want to deal with reentrancy-issues, or because they don't know how to deal with reeentrancy issues.

Besides, I bet few of the tasks in my OS actually gets preempted because they've used-up their timeslice. They will mostly give up their timeslice themselves because they block on events (IOW, they are cooperative). Event-driven designs usually don't have tasks busy-polling things, but rather run some small task and then blocks waiting for more to do.

[Chandra]

People that build OSes or programs for cooperative multitasking usually do this either because they don't want to deal with reentrancy-issues, or because they don't know how to deal with reeentrancy issues.

Or, if they are willing to write all the programs for their OS themselves. No sane developer would ever allow the system to freeze due to the fault of a single application.

[nulik]

Good point. Another reason to use cooperative multitasking.

Cooperative multitasking does nothing of its own to stop context switches, it only makes them happen at points a program finds "appropriate", and therefore does not serve your intended goal.

like I said earlier, context switching costs, and it will cost more as manufacturers increase the amount of registers. An increase in the number of concurrent processes is also performance hit for a preemptive OS. When the number of cores is low you have to pay with a context switch, but as number of cores grows, you will achieve a faster execution if you monopolize a core for an application to do a small task. That will require to change the programming paradigm. It will be hard for the developer, but it is going to be a truly parallel design. Look for example how GPUs work, you have 2,000+ "cores" there, there is not even a slightest idea on the part of the developers to implement context switching.

BareMetal OS is good starting point btw, but it misses the task abortion mechanism, you have to interrupt the whole program if some task code goes into infinite loop.

[OSwhatever]

If you put it this way, is it more cheap to start a fresh thread than resuming an old one?

DSP schedulers has often no preemption and they are often designed so that it does its task and then exits, no blocking during that time. Then you have some sort of multitasking but you never need to save the thread context because DSP jobs are often small and fast. This model might work for many tasks in a general purpose operating system, however not too seldom you need that blocking suspend of the thread as well. However you can reduce the number of context saves this way.

[rdos]

like I said earlier, context switching costs, and it will cost more as manufacturers increase the amount of registers.

It costs just as much to yield in a cooperative environment, because the next task will assume it registers are restored from the previous yield. At least it has the same requirement for state save/restore as a task that blocks on an event, which is the ordinary case in an even-driven OS.

An increase in the number of concurrent processes is also performance hit for a preemptive OS. When the number of cores is low you have to pay with a context switch, but as number of cores grows, you will achieve a faster execution if you monopolize a core for an application to do a small task.

Only if you run some heavy numerical algorithm or something. In the normal case, a thread would block before it's timeslice is up, so there normally is no premption.

That will require to change the programming paradigm. It will be hard for the developer, but it is going to be a truly parallel design. Look for example how GPUs work, you have 2,000+ "cores" there, there is not even a slightest idea on the part of the developers to implement context switching.

Large numerical models requiring 2,000 cores need some heavy optimization regardless of how you implement your OS. The OS could provide help regardless if it is cooperative or preemptive.

[nulik]

I presume you know that you don't have to preserve state of FPU, MMX, SSE, AVX registers on every switch?

The Intel manuals says you have to. If not, where do you save the data then ?

[rdos]

I presume you know that you don't have to preserve state of FPU, MMX, SSE, AVX registers on every switch?

The Intel manuals says you have to. If not, where do you save the data then ?

Study this recent thread for a clue: http://forum.osdev.org/viewtopic.php?f=15&t=24261

[Combuster]

The Intel manuals says you have to.

Nonsense. Proof wanted.

[nulik]

Nonsense. Proof wanted.

nonsense , but on your side

Intel, Software Developer , vol 1:

D.3.6.1 Speculatively Deferring x87 FPU Saves , General Overview

In order to support multitasking, each thread in the system needs a save area for the general-purpose registers, and each task that is allowed to use floating-point needs an x87 FPU save area large enough to hold the entire x87 FPU stack and associated x87 FPU state as the control word and status word

If the processor and the operating system support Streaming SIMD Extensions, the save area should be large enough and aligned correctly to hold x87 FPU and Streaming SIMD Extensions state.

Now, to account how costly it is to save and restore, check the Table C-8a, Apendix C , Instruction Latency and throughput, in the Intel 64 and IA-32 Architectures Optimization Reference Manual:

Code: Select all

Instruction      |       Latency
FXRSTOR                  150
FXSAVE                   100

(MOV has a latency of 1)

Next time it is your turn to provide proofs.

[nulik]

I presume you know that you don't have to preserve state of FPU, MMX, SSE, AVX registers on every switch?

The Intel manuals says you have to. If not, where do you save the data then ?

Study this recent thread for a clue: http://forum.osdev.org/viewtopic.php?f=15&t=24261

Thanks, but ... I don't know, I am not getting something. The manuals say one thing, you guys are saying another. Will have to check that with all details.

Regards

[gerryg400]

Nonsense. Proof wanted.

nonsense , but on your side

Intel, Software Developer , vol 1:

D.3.6.1 Speculatively Deferring x87 FPU Saves , General Overview

In order to support multitasking, each thread in the system needs a save area for the general-purpose registers, and each task that is allowed to use floating-point needs an x87 FPU save area large enough to hold the entire x87 FPU stack and associated x87 FPU state as the control word and status word

If the processor and the operating system support Streaming SIMD Extensions, the save area should be large enough and aligned correctly to hold x87 FPU and Streaming SIMD Extensions state.

Now, to account how costly it is to save and restore, check the Table C-8a, Apendix C , Instruction Latency and throughput, in the Intel 64 and IA-32 Architectures Optimization Reference Manual:

Code: Select all

Instruction      |       Latency
FXRSTOR                  150
FXSAVE                   100

(MOV has a latency of 1)

Next time it is your turn to provide proofs.

The manual says that each thread needs an area to save the FP regs but it doesn't say that you need to actually save the FP regs every time there is a context switch.

A reasonably smart scheduler will make sure that threads that use the FP regs (and other regs saved by FXSAVE) will, as far as is possible, run on the same core each time they are scheduled. That same smart scheduler will also try to keep threads that might compete for FP resources on different cores. The result will be, as long as there are fewer threads using FP resources than there are cores, there will never need to be an FXSAVE or FXRSTOR.

[nulik]

found this:

How long does it take to make a context switch?

Context switching is expensive. My rule of thumb is that it'll cost you about 30µs of CPU overhead. This seems to be a good worst-case approximation. Applications that create too many threads that are constantly fighting for CPU time (such as Apache's HTTPd or many Java applications) can waste considerable amounts of CPU cycles just to switch back and forth between different threads. I think the sweet spot for optimal CPU use is to have the same number of worker threads as there are hardware threads, and write code in an asynchronous / non-blocking fashion. Asynchronous code tends to be CPU bound, because anything that would block is simply deferred to later, until the blocking operation completes. This means that threads in asynchronous / non-blocking applications are much more likely to use their full time quantum before the kernel scheduler preempts them. And if there's the same number of runnable threads as there are hardware threads, the kernel is very likely to reschedule threads on the same core, which significantly helps performance.

URL: http://blog.tsunanet.net/2010/11/how-lo ... ntext.html


--------------------------

[cxzuk]

what are peoples thoughts on non register based chips and there context switches?