[ECOS] context switching in ecos

[ECOS] context switching in ecos

[Suet Fei Li]

Hi everyone:

I am trying to understand the context switching stuff in Ecos here.  It
seems like it goes the following way:

timer interrupt -> save everything on the current thread stack -> call ISR
-> Interrupt_end -> call DSP -> lock scheduler -> call
HAL_THREAD_SWITCH_CONTEXT  -> save current context and load next thread
context -> return from interrupt -> restore everything.

It seems to me that the current status of the CPU has to be saved twice
(once right after the interrupt, the second time during
HAL_THREAD_SWITCH_CONTEXT ). If this is indeed true, isn't it rather
inefficient? Why did not it just:

interrupt -> save everything on the current thread -> scheduler -> load the
context from next thread.

Any input will be very very helpful

thanx a lot

suetfei

Re: [ECOS] context switching in ecos

[Jesper Skov]

>>>>> "Suet" == Suet Fei Li <suetfei@bwrc.eecs.berkeley.edu> writes:
Suet> It seems to me that the current status of the CPU has to be
Suet> saved twice (once right after the interrupt, the second time
Suet> during HAL_THREAD_SWITCH_CONTEXT ). If this is indeed true,
Suet> isn't it rather inefficient? Why did not it just:

Suet> interrupt -> save everything on the current thread -> scheduler
Suet> -> load the context from next thread.

What should happen is that in the VSR all registers that are marked
volatile on calls should be saved. The context switch function should
only save non-volatile registers.

On some architectures, however, there's no (or little) distinction
between the two sets. x86 is probably the worst architecture in this
regard, while most RISC architectures will have two destinct sets.

Jesper

Re: [ECOS] context switching in ecos

[Nick Garnett]

Suet Fei Li <suetfei@bwrc.eecs.berkeley.edu> writes:

> Hi everyone:
> 
> I am trying to understand the context switching stuff in Ecos here.  It
> seems like it goes the following way:
> 
> timer interrupt -> save everything on the current thread stack -> call ISR
> -> Interrupt_end -> call DSP -> lock scheduler -> call
> HAL_THREAD_SWITCH_CONTEXT  -> save current context and load next thread
> context -> return from interrupt -> restore everything.
> 
> It seems to me that the current status of the CPU has to be saved twice
> (once right after the interrupt, the second time during
> HAL_THREAD_SWITCH_CONTEXT ). If this is indeed true, isn't it rather
> inefficient? Why did not it just:
> 
> interrupt -> save everything on the current thread -> scheduler -> load the
> context from next thread.
> 
> Any input will be very very helpful
> 

You have it right there. The main reason for doing it this way is to
avoid the complications of having different kinds of saved thread
state - you often have to save extra state in an interrupt that is not
needed in a straight thread switch. This would also have resulted in
linkage between the thread switch code and the interrupt/exception
handling code. At present they are separate and thus both much
simpler. It makes all the thread switch and scheduler lock code much
more streamlined and sharable because there is no essential difference
between a thread switch as a result of an interrupt and one as a
result of a kernel API call.

The problem of saving the thread state twice can be avoided by only
saving partial CPU states in the two places. This exploits the calling
conventions so that only callee-saved registers are saved in the
thread switch code and only caller-saved registers are saved in the
interrupt code. In the case of an interrupt causing a thread switch,
the whole CPU state is then spread between the two save areas.

Some HALs have support for this, but since it tends to interfere with
debugging, it is not enabled by default.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] context switching in ecos

[Hugo 'NOx' Tyson]

Suet Fei Li <suetfei@bwrc.eecs.berkeley.edu> writes:
> I am trying to understand the context switching stuff in Ecos here.  It
> seems like it goes the following way:
> 
> timer interrupt -> save everything on the current thread stack -> call ISR
> -> Interrupt_end -> call DSR -> lock scheduler -> call
> HAL_THREAD_SWITCH_CONTEXT  -> save current context and load next thread
> context -> return from interrupt -> restore everything.
> 
> It seems to me that the current status of the CPU has to be saved twice
> (once right after the interrupt, the second time during
> HAL_THREAD_SWITCH_CONTEXT ).

To amplify what Nick said slightly...

But consider: a voluntary call to deschedule (like sleep() or a wait()
call) is a function call - the caller will have saved their registers
already.  Only (a subset of) callee-save registers need to be saved.  With
some procedure call standards, a voluntary deschedule needs to save almost
nothing except the stack pointer.

Further, an interrupt must save a few registers away *right now*, in order
to get workspace to handle the interrupt.  But next it makes a standard
sort of function call - which saves callee-save registers.  So the initial
"right-now" save doesn't need to save them all.

So if a thread stopped 'cos of a call into the scheduler, a few registers
are saved in the threadstate, and the rest of what's required is saved in
the call stack frame created when the task made that function call.

If a thread stopped 'cos of an interrupt, a few regs are saved in the stack
in a special interrupt-type stack context, the rest are saved in the stack
in a procedure-call related frame.  That's where the interrupted context
lives, entirely.  BUT there is a further set saved from the call into the
scheduler - that makes sure than when this thread restarts, it runs the
finish of the interrupt handler and restores the interrupted context from
the special interrupt-type stack context.  So the saved context in the
thread state is like a pointer to code that will get the real context off
the stack.

The point of all this is: the code to restart a thread does not need to
know whether it volunteered to deschedule, or it was interrupted.  The
contexts are handled the same way.  One takes you to your synchronous
function call with lots of state on the stack, the other takes you to the
end of the interrupt handler, which will return-from-interrupt using
whatever CPU-specific magic is needed.

> If this is indeed true, isn't it rather
> inefficient? Why did not it just:
> 
> interrupt -> save everything on the current thread -> scheduler -> load the
> context from next thread.

Because that sequence is really:

 interrupt -> save everything on the current thread -> save some registers
 again on stack in function call -> scheduler -> load the context from
 next thread -> restore some regs again from stack in function return

which is inefficient.  
And when it doesn't reschedule at all, the sequence

 interrupt -> save everything on the current thread -> save some registers
 again on stack in function call -> scheduler -> load the context from
 *SAME* thread -> restore some regs again from stack in function return

is very very inefficient! ;-)

	- Huge

RE: [ECOS] context switching in ecos

[Jesper Skov]

>>>>> "Suet" == Suet Fei Li <suetfei@bwrc.eecs.berkeley.edu> writes:

Suet> thanx a lot for the reply.  Could you please give me some sort
Suet> of example of a RISC architecture that this would work? Like a
Suet> processor model that comes with the code?

Suet> I am only familiar with ARM, which has a RISC architecture.
Suet> Seemingly it saves everything on a VSR though.

PowerPC.

Jesper