Messages in this thread | | | Date | Mon, 12 Mar 2001 00:46:22 +0100 (CET) | From | Davide Libenzi <> | Subject | Re: sys_sched_yield fast path |
| |
On 11-Mar-2001 Anton Blanchard wrote: > >> This is the linux thread spinlock acquire : >> >> >> static void __pthread_acquire(int * spinlock) >> { >> int cnt = 0; >> struct timespec tm; >> >> while (testandset(spinlock)) { >> if (cnt < MAX_SPIN_COUNT) { >> sched_yield(); >> cnt++; >> } else { >> tm.tv_sec = 0; >> tm.tv_nsec = SPIN_SLEEP_DURATION; >> nanosleep(&tm, NULL); >> cnt = 0; >> } >> } >> } >> >> >> Yes, it calls sched_yield() but this is not a std wait for mutex but for >> spinlocks that are hold a very short time. Real wait are implemented using >> signals. More, with the new implementation of sys_sched_yield() the task >> release all its time quantum so, even in a case where a task repeatedly >> calls >> sched_yield() the call rate is not so high if there is at least one process >> to spin. And if there isn't one task with goodness() > 0, nobody cares >> about >> sched_yield() performance. > > The problem I found with sched_yield is that things break down with high > levels of contention. If you have 3 processes and one has a lock then > the other two can ping pong doing sched_yield() until their priority drops > below the process with the lock. eg in a run I just did then where 2 > has the lock: > > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 1 > 0 > 2 > > Perhaps we need something like sched_yield that takes off some of > tsk->counter so the task with the spinlock will run earlier.
Which kernel are You running ?
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |