Date: Thu, 7 Jan 1999 03:35:52 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dot@dotat.at (Tony Finch) Cc: hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... Message-ID: <199901070335.UAA11431@usr09.primenet.com> In-Reply-To: <E0zxstX-00060r-00@fanf.noc.demon.net> from "Tony Finch" at Jan 6, 99 01:21:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >In fact we have a port of the linux threads to FreeBSD so we can do > >EXACTLY what they do, including the kernel support. It's being worked on > >as we speak. Some is already committed to -current. There is little > >argumant however that the ultimate is to schedule N threads over M > >processes where M is related to teh number of CPUs available. > > Sometimes you want M to be large relative to the number of CPUs > because you are using threading to improve userland IO concurrency. Finish the thought: "...and you don't want to use async I/O to improve I/O concurrency because, while doing so would be less overhead than using a bunch of threads, it doesn't accomplish your *real* goal." The *real* reasons you use M threads, where M > N, are: 1) You set M := N + 1 because you haven't implemented a cooperative scheduler, and you use the "+ 1" thread to spawn other threads each time you hit a blocking operation in the kernel because you are using threads as a poor substitute for asynchronous call contexts because some idiot on the POSIX committed thought that make a duplicate incomplete subset of the existing system calls to get async I/O was a fine idea. 2) You set M > N + 1, because you want to compete with the other processes on the system as M quantum units as work instead of as N quantum units of work, and you don't care how much context switch thrashing you generate while you are doing it because your process is so important compared to the other processes (that are doing the same damn thing to try and screw your process the same way) that you're willing to be evil instead of dealing with the "scheduler class" issue like a computer scientist. Which leads to: a) Hey! Why is 90% of my time spent in "system" instead of "user", and profiling shows that it's all in the scheduler and the pager? b) You write a scheduler class to give your X server a fixed percentage of the available quantum because you don't have working set limits on a per process or per vnode basis, and your stupid linker mmap's the object files, and without a working set limit to stop it, thrashes your entire X server out of core, and your naieve soloution is to give the X server enough of the CPU that it can thrash itself back in to give the appearance of "good interactive response" to the "move mouse, wiggle cursor" problem. You call the scheduler class "fixed(*)", which the underlying problem definitely isn't. * Any similarity to UnixWare(tm), Linux, or *BSD, running or stuck thrashing pages in and out of core for no good reason, is purely intentional. 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901070335.UAA11431>