Thread (58 messages) 58 messages, 17 authors, 2007-03-06

Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

From: David Miller <davem@davemloft.net>
Date: 2006-09-19 19:40:31
Also in: lkml

From: David Lang <redacted>
Date: Mon, 18 Sep 2006 14:57:04 -0700 (PDT)
yes tcpdump may be wrong in requesting timestamps (in most cases it
probably is, but in some cases it's doing exactly what the sysadmin
wants it to do), but I don't think that many sysadmins would expect
this much of a performance hit.  there should be some way to tell
the system to ignore requests for timestamps so that a badly behaved
program cannot cripple the system this way (and preferably something
that doesn't require a full SELinux/capabilities implementation)
tcpdump is not wrong in requesting timestamps, and there are
many legitimate userland programs that call gettimeofday()
for internal timestamping _A LOT_.  Such as X11 clients.

The real fact of the matter is that these x86_64 systems are using the
slowest possible time-of-day implementation, simply because it's "too
hard" currently to properly probe the most efficient mechanism which
is present in the system.

If getting the time of day is at the top of the profiles in the packet
input path, and we're only capturing a timestamp once per packet,
something is _VERY VERY_ wrong with the timestamp implementation
because think of all of the other seriously expensive things that
happen on a per-packet basis which should absolutely dwarf
timestamping in terms of cost.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help