Alexander Kjeldaas <astor@fast.no> writes:> There is something else we might need as well: Yielding to a specific> process.> > The problem manifests itself in large threaded programs. Say you have> a couple of hundred threads in a program. In these programs, there> will always be some bottlenecks. Locks surrounding malloc() is a> typical example. Lots of processes will block trying to allocate> memory. After the process that has aquired the lock releases it, all> the other processes will be waked up, leading to a "thundering> herd"-problem exactly like the one happening for networking> applications. Now if we could yield explicitly to the first process> waiting for the lock, we would get acceptable performance again.

But this is exactly what LinuxThreads does! When a mutex is unlocked,a single thread gets taken off the mutex's queue and sent a signal,causing it to wake up.

There is a serialization problem if you have threads constantlyhammering on malloc/free, so that heap contention causes contextswitches on a significant proportion of malloc/free calls (when thatstarts happening, you have problems even for user-space contextswitches). The only way around that is to have multiple heaps(*). Does any other system do this? (For malloc; I know of otherlanguage implementations that do it). For programs with reasonableheap contention, the LinuxThreads/glibc malloc performance should bepretty good.

(*) Given that few malloc calls take >1000 cycles, but to block athread in mutex_lock costs >1000 cycles, it *might* help for a threadto backoff then retry once or twice when locking the malloc locks, butit would only be a win on SMP, and it would need a real program thatcan be demonstrated to suffer from heap contention to show benefit --does anyone have one?

Perhaps it is because user-space thread switches are so very muchcheaper.

I'd like to see a nice implementation of user-on-kernel-threads onLinux, but I'm really not sure it would be a win for typical pthreadsC programs. When you say LinuxThreads loses against FreeBSD threads,is that for micro-benchmarks or real programs?

Dave Wragg

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/