[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: scheduler policy question
Hubert Tonneau wrote:
> Benchmarking Pliant ( 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.041 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site