netdev - Re: loaded router, excessive getnstimeofday in oprofile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48B6FE6C.4080905@cosmosbay.com>
Date:	Thu, 28 Aug 2008 21:37:16 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Denys Fedoryshchenko <denys@...p.net.lb>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Joe Malicki <jmalicki@...acarta.com>,
	David Miller <davem@...emloft.net>, johnpol@....mipt.ru,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	juhlenko@...mai.com, sammy@...my.net
Subject: Re: loaded router, excessive getnstimeofday in oprofile

Denys Fedoryshchenko a écrit :
> On Thursday 28 August 2008, Eric Dumazet wrote:
>> 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.

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





--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html