[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kernel Timeslice

On 17Nov2008 15:19, Steve West <steve cyglan com> wrote:
>> The ticks matter when the threads are competing for cpu, but it looks
>> like in your case they'll mostly be waiting for socket calls (during
>> which the schedular will hand off to another thread anyway), so
>> increasing the timeslice frequency is probably not going to make a
>> difference. Hard to know without testing of course.
> Yes you are correct under "NORMAL" circumstances 100 ticks per second
> would be ok. But if I design for worst case where all threads are running
> I need 1000 ticks per second, or response will not be good. I did not want
> to build a custom kernel, but it looks like I may have to to achieve the
> design goal.

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.

Cameron Simpson <cs zip com au> DoD#743

Ride with a llama and you never ride alone.
        - Jeff Earls, DoD #0530, <jearls tekig6 pen tek com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]