Date: Thu, 22 May 2003 22:09:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Julian Elischer <julian@elischer.org> Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads) Message-ID: <3ECDACF2.CF7A637A@mindspring.com> References: <20030522042922.GC13024@dan.emsphone.com> <3ECCF855.6A0E8830@mindspring.com> <20030522165229.GA1694@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (May 22), Terry Lambert said: > > Make sure you use SCHED_4BSD, rather than SCHED_ULE, if you are using > > one of the kernel threads libraries, for now. > > > > You really should read the -current archives before attempting any of > > this, if you don't follow -current closely enough to have caught > > Jeff's message on this, or which kernel threading libraries are > > available. > > I do read -current, and I'm definitely not going anywhere near > SCHED_ULE. I just tested both libraries with today's kernel and > libraries, and was able to get a hard lockup with both libthr and > libkse. Mysql seems to run okay. Starting a threaded pike process > seems to be the killer. Unfortunately, pike's a pretty large app so > it's not easy to get a stripped-down testcase. The philosophies behing libthr and libkse are different. For libthr, you basically have a FreeBSD version of Linux threads; for libkse, there are some issues you have to deal with. The first of these issues is that you have to add Daniel's patch to the libkse scheduler code. This is necessary because there is a lot of threads code that is not completely compliant with the POSIX standard: it makes assumptions which POSIX does not permit, about what thread gets scheduled to run after an involuntary context switch. The original Netscape (e.g. 4.7) has this same assumption, and Java interfaces that use image maps lock it up if you move the mouse over the map while the GIF is loading. If you wait for it to load, there's no problem. Mozilla has similar assumptions. The second of these is that the libkse model is M:N, with N being defaulted to 1. If you want more kernel threads, you have to ask for them (and you aren't doing that). In general, a lot of code is going to assume for M:N that M==N; to get this, you will need to create threads with an attribute other than the default of "NULL", with the scope set to PTHREAD_SCOPE_SYSTEM. You should also look at the actual scheduler code in libkse to see if there are any other requirements for creating KSEG's for KSE's for user space threads (I haven't looked at it for several weeks now, so I don't know if anything has changed, unless it was sent to one of the mailing lists). With both of these out of the way, libkse should work for you. The libthr may not work for you due to scheduling order, or it may not work for you because signals are not masked per process, or it may not work if you have threads that depend on the PTHREAD_SCOPE_PROCESS attribute (kernel threads like the Linux model are inherently incapable of supporting this scope). Basically, you'll have to play around a bit with it. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECDACF2.CF7A637A>