Kernel Timeslice

[Wayne Feick]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20081117/223baf0c/attachment-0001.htm>