Messages in this thread | | | From | Anton Blanchard <> | Date | Mon, 12 Mar 2001 00:54:48 +1100 | Subject | Re: sys_sched_yield fast path |
| |
> 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.
Anton - 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/
| |