When doing an ipset restore with newer versions of glibc I'm seeing some
extra syscall overhead that I was not seeing with glibc 2.4. I was
wondering if anyone has seen such behavior and could help me understand
what is going on?
Here is a snippet of strace during the restore with glibc 2.4:
http://pastebin.com/qxkPF7FB and one with glibc 2.7:
http://pastebin.com/wga9SN0E
I've also seen similar behavior with glibc 2.11.
You'll notice that with the newer version a second netlink socket is
created and it appears some data is sent and info received back from the
kernel and that socket is closed. This creating and closing of sockets
continues until the restore operation completes. This causes the restore
to grow from taking ~1 second to ~5 seconds. This is not a huge deal,
but I'm more curious as to why this behavior has changed.
These runs were done with ipset v6.11 and kernel 3.2. It appears to me
this is a glibc change b/c if I swap out only that component I see this
change in behavior.
Thanks
Josh
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
