Messages in this thread | | | Date | Sun, 11 Mar 2001 15:12:57 +0100 (CET) | From | Davide Libenzi <> | Subject | Re: sys_sched_yield fast path |
| |
On 10-Mar-2001 Andi Kleen wrote: > Davide Libenzi <davidel@xmailserver.org> writes: > > >> Probably the rate at which is called sys_sched_yield() is not so high to let >> the performance improvement to be measurable. > > LinuxThreads mutexes call sched_yield() when a lock is locked, so when you > have a multithreaded program with some lock contention it'll be called a > lot.
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.
- 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/
| |