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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
scheduler policy question
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/