Messages in this thread |  | | Date | Wed, 06 Sep 2000 06:51:01 -0700 | From | George Anzinger <> | Subject | Re: scheduler policy question |
| |
Hubert Tonneau wrote: > > 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 ?
NO. Yield has been broken more than not. It is broken in 2.4.0-test6 for example.
> 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 ?
One answer is to jump to a real time priority. Fall back when you want to yield. Problem is you need root priv to do the call.
George - 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/
|  |