Thread (8 messages) flat view 8 messages, 3 authors, 2021-10-29

Re: [PATCH] arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

From: Mark Rutland <mark.rutland@arm.com>
Date: 2021-10-29 15:08:25

On Thu, Oct 28, 2021 at 02:45:42PM +0100, Mark Rutland wrote:
I had a go with the selftests and there are some latent issues which show up on
a pristine v5.15-rc4 (or v5.15-rc7), using defconfig + the ftrace selftest
config fragment, including an OOM that could be a memory leak.
Later the tests hang in:

| [19] event tracing - enable/disable with subsystem level files

... and from trying:

| # ./ftracetest -vvv test.d/event/subsystem-enable.tc 

... it seems to hang after the usual reset, on the first part of the
test, with the last output being:

| + . /root/ftrace/test.d/event/subsystem-enable.tc
| ++ echo 'sched:*'
| ++ yield
| ++ ping 127.0.0.1 -c 1
| PING 127.0.0.1 (127.0.0.1): 56 data bytes
| 64 bytes from 127.0.0.1: seq=0 ttl=64 time=2.442 ms
| 
| --- 127.0.0.1 ping statistics ---
| 1 packets transmitted, 1 packets received, 0% packet loss
| round-trip min/avg/max = 2.442/2.442/2.442 ms
| +++ cat trace
| +++ grep -v '^#'
| +++ awk '{ print $5 }'
| +++ sort -u
| +++ wc -l            
In the end, this is because my test VM has 32 vCPUs and can create a
tremendous amount of trace information. So much so that userspace spends
an incredibly long time parsing it and trying to sort it.

If I boot a 2 vCPU VM, this passes after a couple of seconds.

I have a local patch to make the test more robust to this, which I'll
send out in a bit. There are some other tests that want to scan the
entire trace stream though, so practically it's necessary to run those
with fewer CPUs.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help