Denys Fedoryshchenko a écrit :

On Thursday 28 August 2008, Eric Dumazet wrote:

quoted

2) You maybe have a bad program that do something expensive relative to
kernel time services.

No, process list is very short, it is custom semi-embedded linux distro i 
made, so i know each process running there.  Here is process list (kernel 
processes/threads and running shell(busybox ash) removed) 

1 root     /bin/sh /init
 1119 root     init
 2451 root     /sbin/syslogd -R 80.83.17.2
 2453 root     /sbin/klogd
 3168 squid    /usr/sbin/zebra -d
 3175 squid    /usr/sbin/ripd -d
 3195 root     /usr/sbin/snmpd -c /config/snmpd.conf
 3208 root     udhcpd /config/udhcp.office.conf -S
 3550 root     /usr/sbin/sshd -b /etc/banner
 3566 root     /sbin/getty 38400 tty1
 3567 root     /sbin/getty 38400 tty2
 3570 root     /sbin/getty 38400 tty3
 4055 root     /usr/sbin/sshd -b /etc/banner

OK, please try oprofile with call graph analysis.

quoted

kernel already provides nanosecond resolution :)
Check SO_TIMESTAMPNS and SCM_TIMESTAMPNS

Maybe this function really must be "heavy" then.

Nope... the contrary :)

Kernel timestamping has nanosec resolution.

SO_TIMESTAMP needs a divide (by 1000), while SO_TIMESTAMPNS is native.