Date: Thu, 26 Oct 2006 21:33:43 +0000 From: John Birrell <jb@what-creek.com> To: current@freebsd.org Subject: HEADSUP: KSE about to become a kernel option Message-ID: <20061026213343.GA29160@what-creek.com>
next in thread | raw e-mail | index | archive | help
If you use a GENERIC kernel, then this change won't affect you because the KSE option will be on by default in GENERIC on all arches/machines except sun4v (which doesn't handle signals properly with the KSE code in the kernel). If you use a custom kernel, you need to add 'options KSE' to your kernel config to continue to use libpthread. If you use libmap to map libpthread.so.2 to libthr.so.2, then you can use a kernel with or without 'options KSE'. KSE has been declared as a kernel option in src/sys/conf/options for a while now, so even though I haven't committed any files which use it, you can add it to your kernel config right now so that you are ready for when the cvs changes make their way out to the cvsup mirrors. I am planning on getting DTrace into current by the end of this year and one of the first things I want to use it for is to measure the differences between libpthread and libthr to see where we suck compared to Linux and Solaris. To date people have anecdotal tales to tell about one being better than the other, but we haven't had a good way to measure exactly what it is that is causing the poor relative performance. With this change, it is possible to build a GENERIC kernel (with KSE support) and a !KSE kernel and alternately boot between the two while using the exact same installed ports of your favourite threaded applications. Hopefully, if you care about threaded performance in FreeBSD, you will be prepared to help run DTrace (when it becomes available) on _your_ system the way _you_ like it to measure which thread implementation is better for _you_. Out of this I hope to determine which thread implementation deserves to be the default, and possibly conclude that one thread implementation doesn't stand up in comparison with Linux and Solaris. I also hope to get enough info to write a paper about the use of DTrace in FreeBSD, possibly for BSDcan 2007. I realise that the source changes to make KSE a kernel option will offend some people because they are essentially a lot of #ifdefs. This is deliberate because it shows what code would remain if KSE support was to be ripped from the kernel. Yes, the code will be more complex to maintain. -- John Birrell (with flame suit on)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061026213343.GA29160>