On Tue, 2008-11-18 at 07:51 +1100, Cameron Simpson wrote:

Do you really expect all 1000 to be CPU bound? Most machines would give
terrible response no matter the tick rate.

As I recall, the tick rate only matters when the threads are, as Patrick
said, _competing_ for CPU. Most TCP handlers will wake up, accept the
connection, maybe send some data, and then _block_. Really fast. Well
under 1/1000th of a second. The tick rate is how long a single thread
can use the CPU flat out before a new scheduling decision is made.
If, like most handlers, your threads wake up, do something, then block
(including reading from disk) then it's not such an issue.

Can you elaborate on your app; it is really going to try to run 1000 CPU
bound threads? It will be prtetty unusual.

Agreed. If you really do have 1000 CPU bound threads competing for the CPU, you should be looking at a redesign.

Separate user interaction into a high priority thread pool, and dispatch long running computational tasks to a second, lower priority thread pool. If there is a lot of separate I/O going on as well, put it either into the high priority thread pool, or a medium priority pool in the middle.

The lower priority computational pool should be sized on the order of 1x to 2x the number of cores, depending on whether it's strictly computation or there's some I/O in the mix. If there is a lot of I/O blocking there, you might go even larger on that pool. You'll want to think about how much memory those computational threads need, to avoid thrashing the paging system.

If you're trying to service 1000's of sockets, you should at least take a look at select(2) / asynchronous I/O as a way to cut down on the number of threads and avoid the overhead or many context switches. Remember that each thread has its own stack, so a thousand 8k stacks chews up 8M of memory (not sure what the standard stack size is these days).

Wayne.