Kernel Timeslice

Cameron Simpson cs at zip.com.au
Mon Nov 17 20:51:16 UTC 2008


On 17Nov2008 15:19, Steve West <steve at 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.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

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




More information about the fedora-list mailing list