Re: Scheduler: Spinning until tasks are STOPPED

[Nick Piggin <nickpiggin@yahoo.com.au>]

Yuly Finkelberg wrote:
> Nick,
> 
> 
>>You're doing this in the *kernel*? It sounds like it should be done
>>in userspace or done a different way (ie. not with 50 tasks).
> 
> 
> These are tasks that are running in the kernel on behalf of a new system call.  
> 

Well it still sounds like the kernel is doing too much. For example,
why don't you just have a syscall (or char device) just to send out
the events, and do everything else (all the queueing and
synchronisation and signalling) in userspace?

> 
>>And using signals and spinning on yield for synchronisation and
>>process control in the kernel like this is fairly crazy.
> 
> 
> The problem appears to be not with the process that is
> spinning/yielding, but rather the one process which gets stuck.  It is
> charged almost all the system time.  I agree that it's not pretty
> though...
> 
> 
>>Can't you use a semaphore or something?
> 
> 
> There is noone to call up() when a process is actually stopped.
> 
> If you have any ideas as to what can be happening or a better way to
> accomplish this (in the kernel), I'd appreciate hearing it.
> 

OK, for a simple example, instead of spinning on yield(), do a
down() on a locked mutex.

Then have maybe an `atomic_t nr_running` which is incremented for
each worker task running. When they are ready to stop, they can
do an atomic_dec_and_test of nr_running, and the last one can up()
the mutex. If you absolutely need to know when the process is
actually stopped, why?

Also, sending one's self a SIGSTOP to stop is not so good.
Generally you shouldn't use signals at all in the kernel if
possible. So why don't those guys just return to usermode and you
can raise a signal or whatever you need from there.

-- 
SUSE Labs, Novell Inc.