> Welcome :-). > Thank you :)
> Actually, by default, most mutexes in the system are sleep mutexes, so > they sleep on contention rather than spinning. In some cases, this > actually hurts more than spinning, because if the mutex is released > quickly by the holder, then you pay the context switches which cost > more than spinning for the short period of time. > > You might want to try adding "options ADAPTIVE_MUTEXES" to your kernel > configuration, which will cause mutexes to spin briefly on SMP systems > before sleeping, and has been observed to improve performance quite a > bit. > Interesting; could switching to SCHED_ULE help as well ? Since afaik the processes get re-scheduled? Also could this be the reason that system gets to use so much cpu (like 70% of overal cpu)? That it needs to reschedule ~1000 processes continuesly ? > If you have a lower tolerance for instability, there are a number of > minor performance tweaks that can be easily back-ported to 5.2.1, > such as the change to proc.h to make grabbing and releasing the proc > lock conditional on p_stops having events defined. This removes > several mutex operations from each system call, and I've observed the > difference in a pretty measurable way on micro-benchmarks. It's also > pretty low risk. The change is src/sys/sys/proc.h:1.366. There are > some other related changes that can probably be dug up, including > changes to improve the performance of the scheduler in the presence > of threads, etc. if all else fails i'll start doing this, thanks for the suggestion! -- Ali Niknam <[EMAIL PROTECTED]> | tel 0182-504424 | fax 0182-504460 Transip B.V. | http://www.transip.nl/ | Mensen met verstand van zaken. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
