Ralf Hildebrandt put forth on 12/10/2010 1:39 AM:
- Timo Sirainen tss@iki.fi:
Cor's debugging has so far shown that a single epoll_wait() call can sometimes generate a few thousand voluntary context switches. I can't really understand how that's possible. Those epoll_wait() calls about half of the total voluntary context switches generated by imap processes. We'll see tomorrow if poll() works better or if a small patch I made makes it better.
That sounds promising :)
Has anyone considered a compiler issue? A gcc optimization flags issue? A gcc version issue? Something along these lines?
To generate the number of context switches/sec that has been mentioned, that would seem to indicate a fast loop running more times than it should but without actually doing much, thus not utilizing its full time slice, getting sidelined by the scheduler, but ready to run on each kernel tick. Thus it runs on each kernel tick. Could something like "-funroll-all-loops" be having problems with the 2.0.x source?
I'm talking a bit out of my element here. I know just enough about compiler technology and machine code to make me really dangerous, but not very useful. :) I'm just trying to look outside the box I guess, or leave no stone unturned. Pick you favorite analogy that applies.
Cor and Ralf, are you two using the same gcc version? Same flags? Are they different than the switches/flags most other 2.0.x OPs are using when they make the source?
-- Stan