Date: Thu, 2 Dec 1999 21:18:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: davids@webmaster.com (David Schwartz) Cc: kris@hub.freebsd.org, jcm@dogma.freebsd-uk.eu.org, freebsd-chat@FreeBSD.ORG Subject: Re: threads.... Message-ID: <199912022118.OAA28482@usr08.primenet.com> In-Reply-To: <000401bf2e65$ffd3d2f0$021d85d1@youwant.to> from "David Schwartz" at Nov 13, 99 10:03:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
I didn't see answers on this... > > > Here's a perfect example of when threads matter.. i want the newest > > > version of Licq. The newest, with all recent fixes, is 0.71. But i > > > have to DL 0.61 because after that they became THREADED! I hope we have > > > threads (kernel) soon. > > > > We already have threads. How exactly does licq (an ICQ client) rely on > > kernel-supported threads (only needed for some level of SMP scalability?) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You're joking right? Or do you think that real-world server applications > don't mind if you freeze everything while the kernel services a page fault > or reads a file from a slow disk? The question is why the application is threaded; there are a number of reasons to thread an application: 1) In order to have seperate, similar (or identical) "tasks" operating in parallel. In other words, in order to obtain multiple program counters. NB: I believe this is th ICQ case 2) To achieve some level of concurrency on a UP system by interleaving rather than serializing I/O. NB: This can be accomplished using async I/O NB: This can be accomplished using non-blocking I/O, if the systems I/O subsystem is built to take the hint that it got and queue the read-ahead before returning the "EWOULDBLOCK" to user space 3) To achieve SMP scaling by giving the kernel scheduler discrete object to apply the quanta from more than one CPU, in order to get multiple CPUs into user space in a single process. If the kernel is servicing a trap, then the SMP lock on the scheduler is held, and no other calls, traps, or interrupts can enter the kernel until the current one has completed servicing. This is true of FreeBSD and Linux systems, and, if we discount interrupt processing in kernel threads, of BSDI, as well. NT has proven, rather well, that tying network card interrupts to particular CPUs, rather than running in a fully symmetric virtual wire mode, one can achieve much better locality of reference, and thus better performance. This is why Linux lost on the Netcraft and ZDLabs tests against NT on quad processor, quad ethernet Xeon systems, and why FreeBSD lost in the unpublished ZDLabs testing on FreeBSD on the same systems. Therefore, the only reason for kernel threads on FreeBSD, Linux, or BSDI at this time is SMP scalability. As a means of SMP scaling, this approach leaves a hell of a lot to be desired, since it does not address the CPU affinity, thread group affinity, or significantly increased context switch overhead issues. If you are not running SMP, then a user space call conversion scheduler utilizing async I/O or non-blocking I/O has much better thread group affinity, and much lower context switch overhead than a kernel threads implementation. Hope that answers your question; if it doesn't, please see the current discussion on -arch in the mailing list archives to see what a real low overhead, SMP scalable, threading system has to look like. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912022118.OAA28482>