Benchmarking Pliant (http://pliant.cx/) semaphores led to unexpectedly
low results. The problem to either kernel bad features or bugs in my
program since Pliant uses no glue library such as glibc: it calls
directly kernel funtions.
Not enough scheduling problem:
-----------------------------
I traced the problem to the fact that when the semaphore is locked,
I call sched_yield kernel function expecting that it will switch
to another thread, whereas my results seem to mean that it does not.
On the other hand, calling nanosleep kernel function with 0 as tv_sec and
tv_nsec does exactly what I would have expected from sched_yield.
Did I misunderstood sched_yield semantic ?
So, sched_yield function seems to do nothing on my 2.2.15 UP box. On the other
hand, on my 2.0.38 SMP box, it seems to work as expected (same as nanosleep 0)
Too much scheduling problem:
---------------------------
In order to restart a stopped thread (which sent a SIGSTOP signal to itself),
I send a SIGCONT signal to the target thread using kill kernel function.
The problem here is that it seems (also what I deduced from benchmarks) that
the calling thread will be preempted immediatly.
This is a big problem in the case I want to restart a set of threads
at once (in case they are waiting for read access on a semaphore) and also a
small one in the very general case since they is too much ping pong between
the various threads dealing with the semaphore resulting in too much wasted
time in the kernel scheduler.
So my question is how can I restart another thread and continue running
the current one until it's time slice ends ?
Thanks,
Hubert Tonneau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:26 EST