Pablo Neira Ayuso wrote:
Patrick McHardy wrote:
Pablo Neira Ayuso wrote:
Pablo Neira Ayuso wrote:
Patrick McHardy wrote:
These calculations look somewhat expensive to perform for every
message.
Do you have any numbers for this new patch that shows the difference
in CPU usage compared to the resizing done by af_netlink.c?
Fabian Hugelshofer reported some reduction (~5%) on an embedded
environment but he was using top to measure the difference. I'll collect
some more trustable data and get back to you.
Some oprofile results:
wo/patch
2189 0.0305 nf_conntrack_netlink.ko nf_conntrack_netlink
ctnetlink_conntrack_event
w/patch
2302 0.0440 nf_conntrack_netlink.ko nf_conntrack_netlink
ctnetlink_conntrack_event
While __alloc_skb and netlink_broadcast report similar values for w/ and
wo/ the patch.
So its actually getting worse? :) Any other differences, like less
cycles for memcpy in netlink_trim()?
netlink_trim is inlined, so it is included in netlink_broadcast, and
there's no improve in memcpy nor netlink_broadcast. I'm going to repeat
all the test to check if I'm doing something wrong, until that, let's
keep it back.
Thats really strange, there has to be at least some reduction of work
because we should be avoiding the packet copy in netlink_trim. Unless
there's a bug somewhere in the calculation and we're still
overallocating by more than 50%.
--
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
