Re: top hogs CPU in 2.6: kallsyms_lookup is very slow

[Denis Vlasenko]

On Thursday 16 September 2004 15:17, William Lee Irwin III wrote:
> At some point in the past, I wrote:
> >> As for all syscalls/etc. being slower by 50%-100%, I suggest toning
>
> On Thu, Sep 16, 2004 at 02:57:08PM +0300, Denis Vlasenko wrote:
> > s/all/many/:
> > uname <0.000142> ? ? ? ? ? ? ? uname <0.000217>		25% slower
> > brk <0.000176> ? ? ? ? ? ? ? ? brk <0.000174>		no change
> > open <0.000218> ? ? ? ? ? ? ? ?open <0.000335>		33% slower
> > fstat64 <0.000104> ? ? ? ? ? ? fstat64 <0.000191>	90% slower
> > or maybe strace simply isn't very accurate and adds signinficant
> > noise to the measured delta?
>
> Could you try to estimate the resolution of whatever timer strace uses?
>
> At some point in the past, I wrote:
> >> down HZ (we desperately need to go tickless) and seeing if it persists.
> >> Also please check that time isn't twice as fast as it should be in 2.6.
>
> On Thu, Sep 16, 2004 at 02:57:08PM +0300, Denis Vlasenko wrote:
> > I recompiled 2.6 with HZ=100. It's not it.
> > Time is running normally too.
>
> Did the kallsyms patches reduce the cpu overhead from get_wchan()? I take
> this to mean reducing HZ to 100 did not alleviate the syscall problems?
> How do microbenchmarks fare, e.g. lmbench?

Not a lmbench, but:

#include <fcntl.h>
int main() {
    int fd;
    int i=100000;
    while(i--) {
        fd = open("/etc/ld.so.cache", O_RDONLY);
        close(fd);
    }
    return 0;
}

2.4:
# time ./openclose
real    0m7.455s
user    0m0.300s
sys     0m7.150s

2.6:
# time ./openclose
real    0m8.170s
user    0m0.370s
sys     0m7.800s

2.6 is at HZ=100 here. /etc is on ramfs.
configs are in attached tarball.
--
vda

Attachment: c.tar.bz2
Description: application/tbz