On Tue, Feb 20, 2007 at 09:48:59PM +0300, Evgeniy Polyakov wrote: > Likely first overhead related to cache population or gamma-ray radiation. > If it happens only one (it does in my test), then everything is ok I > think. Bert, how frequently you get that long recvfrom()?
I have plotted the average time for a single non-blocking UPDv4 recvfrom call returning 100 bytes, based on the delay I insert between recvfrom calls, as measured in cycles spent busywaiting. In theory, this graph should show some slope, perhaps because of the higher chance of context switches, cache evictions and purging of any branche-prediction information the CPU might have kept. I'm no expert. I measure a huge slope, however. Starting at 1usec for back-to-back system calls, it rises to 2usec after interleaving calls with a count to 20 million. 4usec is hit after 110 million. The graph, with semi-scientific error-bars is on http://ds9a.nl/tmp/recvfrom-usec-vs-wait.png The code to generate it is on: http://ds9a.nl/tmp/recvtimings.c I'm investigating this further for other system calls. It might be that my measurements are off, but it appears even a slight delay between calls incurs a large penalty. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
