>>>>> On Tue, 21 Dec 2004 17:17:32 -0700, >>>>> Scott Long <scottl_at_freebsd.org> said: >> 4. mutex contentions are VERY expensive (looks like much much more >> expensive than other OSes), while trying to get a lock without a >> contention is reasonably cheap. (Almost) whenever a user thread >> blocks due to a lock contention, it is suspended with a system >> call (kse_release), probably causing context switch. (I'm not >> really sure if the system call overhead is the main reason of the >> performance penalty though.) > This might be related to what I said above. Where you observing this > with process scope or system scope threads? Again, if scheduling > decisions are not cheap in the UTS then there really is no point to > SA/KSE. I observed this with system scope threads. Note that "BIND+" I showed in my previous message was modified so that it would specify PTHREAD_SCOPE_SYSTEM. Yet this version ran slower as we increased worker threads. >> 6. at least so far, the ULE scheduler doesn't help improve the >> performance (it even performs worse than the normal 4BSD >> scheduler). > With both types of threads? Yes. Here are some results that were not contained in my previous message: #of process system threads scope scope 1 3014 3090 2 3121 3179 3 2254 1922 4 1869 1405 (the tests were on FreeBSD 5.3 beta 7 w/ ULE + Xeon 700MHz x 4) One remarkable difference is that ULE *relatively* improved the results for process scope threads. However, the BIND server still slowed down with multiple threads. That's why I said "ULE doesn't help improve the performance". > Have you tried Jeff's recent fixes to ULE? I'm not sure. My experience with ULE was limited to the beta7 version of FreeBSD 5.3, and I just gave up using it at that stage, having seen everyone in this list said "ULE is broken, don't use it." If beta7 did not contain the fixes you mentioned, I didn't try them. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei_at_isl.rdc.toshiba.co.jpReceived on Wed Dec 22 2004 - 05:24:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC