Re: Scheduler: Spinning until tasks are STOPPED

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yuly Finkelberg wrote:
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?


True, it does :)
However, the operation requires that a consistent in-kernel state will
hold for the tasks.  They all (except for the last one) do some work,
send a SIGSTOP to themselves, and return to usermode (handling the
STOP signal).  The last task does not stop itself, but instead
verifies that all of the others are stopped before it returns.


Well you can do that all from userspace basically.
At least you should be able to do it as well as you can from
kernel (providing you have a syscall/device to retrieve events).


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?


I need to ensure that the internal state of the processes will not
change (unless of course some other signal gets delivered, which will
not be the case).


They won't change *much*. Nothing that is detectable from userspace
(except for perhaps /proc entries).

It doesn't look like the problem is with the task that is spinning
until the others have stopped.  Instead, it looks like one of the
other tasks is spinning somewhere in between the time that it wakes up
its successor and the time that it sends it self the STOP signal.  It
is clearly getting preempted but then makes no progress (sometimes for
a VERY long time).


Well it is a bit difficult to help further because you haven't posted
the working code or said what you are trying to do.

Stick a few printks around the place or try a kernel debugger to see
if you can't work out what is going wrong. Compiling the kernel with
debug info can allow you to find out what line of code EIP is pointing
to, which can also be helpful.

--
SUSE Labs, Novell Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux