Messages in this thread | | | Date | Sun, 08 May 2005 14:00:03 +1000 | From | Nick Piggin <> | Subject | Re: Scheduler: Spinning until tasks are STOPPED |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |