Re: scheduler policy question

From: George Anzinger (george@mvista.com)
Date: Wed Sep 06 2000 - 08:51:01 EST


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/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:25 EST