I am running a command:
perf top -a -g -e skb:kfree_skb
on a laptop running a 3.18.0-rc2+ kernel from davem's net-next tree.
While that is running I hit the system as the target of a netperf TCP_CC
test (ie netserver is running on the system where perf is running, and
netperf is run on another system, pointing at the first). I then expand
the kfree_skb() line and the sk_stream_kill_queues and
tcp_rcv_state_process lines "within" that expansion.
If I watch with plain "top" in another window I can see the RES value
for the perf process steadily increasing and also its CPU utlization.
The latter finally peaks at 100% (this is a core 2 duo laptop).
After about 1800 seconds of being the target of a netperf TCP_CC test
the RES value for the perf utility is over 1G.
If I wait long enough, perf will finally segfault.
Is this a known issue? If I should file a more formal bug report
somewhere let me know.
happy benchmarking,
rick jones
raj@raj-8510w:~$ net-next/tools/perf/perf --version
perf version 3.17.rc6.g09bba1
netperf -t tcp_cc -H <perfsystem> -l 3600
might need to repeat it a few times to get the segfault?
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
