netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: bert hubert <bert.hubert@netherlabs.nl>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Josef Sipek <jsipek@fsl.cs.sunysb.edu>,
	Andi Kleen <andi@firstfloor.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?
Date: Tue, 20 Feb 2007 14:02:00 -0800	[thread overview]
Message-ID: <45DB6FD8.4050106@hp.com> (raw)
In-Reply-To: <20070220193319.GA8800@outpost.ds9a.nl>

> 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.

The slope appears to be flattening-out the farther out to the right it 
goes.  Perhaps that is the length of time it takes to take all the 
requisite cache misses.

Some judicious use of HW perf counters might be in order via say papi or 
pfmon.  Otherwise, you could try a test where you don't delay, but do 
try to blow-out the cache(s) between recvfrom() calls.  If the delay 
there starts to match the delay as you go out to the right on the graph 
it would suggest that it is indeed cache effects.

rick jones

  parent reply	other threads:[~2007-02-20 22:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-19 23:14 nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz? bert hubert
2007-02-19 23:56 ` Stephen Hemminger
2007-02-20  8:04   ` bert hubert
2007-02-20 10:50 ` Andi Kleen
2007-02-20 16:27   ` all syscalls initially taking 4usec on a P4? " bert hubert
2007-02-20 16:41     ` Evgeniy Polyakov
2007-02-20 17:02       ` bert hubert
2007-02-20 17:11         ` Evgeniy Polyakov
2007-02-20 17:18           ` Evgeniy Polyakov
2007-02-21 11:06           ` Evgeniy Polyakov
2007-02-21 11:34             ` Andi Kleen
2007-02-20 18:42       ` Josef Sipek
2007-02-20 18:48         ` Evgeniy Polyakov
2007-02-20 19:33           ` bert hubert
2007-02-20 19:40             ` Benjamin LaHaise
2007-02-20 20:45               ` bert hubert
2007-02-20 21:02                 ` Stephen Hemminger
2007-02-20 22:02             ` Rick Jones [this message]
2007-02-20 22:17               ` bert hubert
2007-02-20 22:22                 ` Arjan van de Ven
2007-02-21 16:25                   ` Chuck Ebbert
2007-02-20 22:46                 ` Ian McDonald
2007-02-25 10:41       ` Pavel Machek
2007-02-25 17:06         ` Evgeniy Polyakov
2007-02-20 16:57     ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DB6FD8.4050106@hp.com \
    --to=rick.jones2@hp.com \
    --cc=andi@firstfloor.org \
    --cc=bert.hubert@netherlabs.nl \
    --cc=johnpol@2ka.mipt.ru \
    --cc=jsipek@fsl.cs.sunysb.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).