Date: Sun, 26 Apr 1998 06:32:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jasone@canonware.com (Jason Evans) Cc: toor@dyson.iquest.net, toshok@Hungry.COM, freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance Message-ID: <199804260632.XAA28042@usr05.primenet.com> In-Reply-To: <Pine.BSF.3.96.980425142529.14499F-100000@mozart.canonware.com> from "Jason Evans" at Apr 25, 98 02:48:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Threads performance is also very important to SQRL (the Hungry DBMS), so See other post. The performance seen is probably a use model problem. > I'm very interested in how the pthreads library that uses clone() will be > architected. Specifically, will we be doing the same as LinuxThreads > does, with a 1:1 mapping of threads to kernel "processes"? I tend to > think that a multi-level threading scheme, such as what Solaris uses, has > the potential for better scalable performance. Solaris (and SVR4.2 derived) kernel threading is arguably Very Broken for most of their recommended use models. Specifically, the use models are subject to thread quantum starvation, even in the face of available process quantum going unused. The only use model where this isn't the case is the one-thread spawn ahead with autothread creation when there are runnable user space threads and all kernel threads but the one that does the spawning are currently busy with blocking calls. Ultimately, the only fix is a cooperative user space scheduler. AIO helps a lot, but there are blocking calls that are not dealing with vanilla fd's. Ultimately, the fix for this would be an async call gate for all system calls, and per system call falgging about whether the call is non-blocking, potentially blocking, or definitely blocking, and the addition of a call context management interface (cancel, wait, etc.). Probably you would want to build POSIX AIO on top of the async call gate, rather than adding async versions of existing calls, and missing the blocking calls that POSIX misses because they expect the problem to be I/O blocking and concurrency. But enough about Solaris/SVR4.2. 8-). > It's also a good bit > harder to write such a library. =( We'd also need to understand the > performance problems with our current user-land threads library to make > multi-level threads work well. The general problem with a user space threads library is starvation of threads in the case of a CPU intensive thread not calling explicit thread_yield() when it fails to call system calls to implicitly yield. 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?199804260632.XAA28042>