Re: Kernel Timeslice

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

 



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.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux