On Sun, 07 May 2006 15:45:09 +0200 [EMAIL PROTECTED] wrote: > > But xen is not working well with the tls/nptl glibc version. > > There is a big fat warning, that performance is reduced when doing so. > > im using xen 3.x on a stock tsl 2.2 and work nicely... > where're the problems ???? In TSL2.2 there are no problems, but who is running 2.2 with kernel 2.4 anyway :)
TSL2.2 glibc is build against kernel 2.4 and is using the linuxthreads implementation; db4 uses own(?) mutexes. TSL3.0 glibc is build against kernel 2.6, which make it possible to use the much faster Native Posix Thread Library; and db4 is build against that. (http://en.wikipedia.org/wiki/NPTL / http://en.wikipedia.org/wiki/Futex) (NTPL implies Thread Local Storage or TLS, which is the root of the problem :) "In tests, NPTL succeeded in running 100,000 threads simultaneously on a IA-32 which were started in two seconds. In comparison, this test under a kernel without NPTL would have taken around 15 minutes." IIRC the problem is, that both tls and xen uses negative segment addressing when accessing a different threadgroup(?) / not their own domain. When xen and tls is used at the same time, every memory access must be double checked by the xen-hypervisor (other domain or just an other threadgroup on the same domain). (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html 2.5.3) In fact, there are two librarys used in TSL3.0: /lib/libc.so and /lib/tls/libc.so The former is the "linuxthread" version, and the later is the "nptl+tls" version. One can force to use the linuxthread version by renaming the tls directory. This is also suggested by xen when recompiling glibc is not a option. (http://wiki.xensource.com/xenwiki/XenFaq 4.1) Fedora & others have a special xen version of glibc to avoid this. Olaf _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
