| |||||||||||||
|
| |||||||||||||
Making Linux safe for pthreadsMaking Linux safe for pthreadsPosted Aug 15, 2002 6:13 UTC (Thu) by IkeTo (subscriber, #2122)Parent article: Making Linux safe for pthreads I might be mistaken, but I really think that all the work cannot make it affordable to create, say, 1000 threads by a single process. My worry is that a thread is not cheap to the kernel at all. Each thread requires its own task_struct, which means one page of memory. To create 1000 threads in a program, it means 4M space will be needed for holding these task_struct's. And these pages are in the kernel, i.e., they cannot be put into the swap space even if all the 1000 threads are sleeping. The old wisdom is that to support many threads, one need user-mode threads that maps to threads within the kernel, which is not what provided by the pthread library. Of course, the kernel patches improves the efficiency of thread creation and destruction. But does it mean that creating 1000 kernel threads in a process is no longer a really broken behaviour?
(Log in to post comments)
Making Linux safe for pthreads Posted Aug 15, 2002 10:06 UTC (Thu) by stevelinton (guest, #3274) [Link] OK, so 1000 threads consumed 4MB of unswappable kernel memory. How is this a problem? Maybe on some embedded systems, but even a palmtop usually has 64MB today, and a laptop at least 128MB. Anyway 1000 threads probably means a high-end server task, and no serious server today has less than 1GB of RAM.
Making Linux safe for pthreads Posted Aug 16, 2002 20:41 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I think 1000 threads implies high end server only because the threads are so expensive. If they were cheaper, we could use that mechanism on old cheap computers for simple things too. There are LOTS of old machines with less than 64MB of memory that would be nice to be able to use. (My primary machine, that I use for mail, web browsing, compiling, database, and other routine computing has 40 MB).There remains the irony that it takes 8K of state information and stack space to do with a Linux thread what would take only a few words to do in a non-thread alternative. Hence the idea that there must be some waste there that can be reclaimed.
In defense of thousands of threads Posted Aug 15, 2002 16:13 UTC (Thu) by bhurt (guest, #3281) [Link] The problem with user-space threads is that when one thread blocks, for whatever reason, all threads block. For library calls (read, write, etc) this can be worked around with some difficulty (does Linux support asynchronous I/O yet?). For page faults, the only work around is to spawn more threads than CPUs- that way, when one thread blocks due to a page fault another thread can run.If you assume a couple dozen CPUs, each needing a couple dozen threads to make sure there is always at least one thread that is runnable, you get into thousands of threads really quickly. Brian
In defense of thousands of threads Posted Aug 19, 2002 11:21 UTC (Mon) by shane (subscriber, #3335) [Link] IBM is currently working on the Next-Generation POSIX Threads effort, which seems to combine the best of both worlds. It creates multiple kernel threads (by default based on the number of CPU's), but not one per user thread. In this way, the kernel doesn't waste time multitasking thousands of kernel threads, but not all threads block if one is busy hogging the context in a computation loop, for instance.Check out the home page: http://www-124.ibm.com/pthreads/ BTW, it's based on GNU Pth.
|
|
||||||||||||