aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorJakub Kicinski <kuba@kernel.org>2024-07-03 19:42:33 -0700
committerJakub Kicinski <kuba@kernel.org>2024-07-03 19:42:34 -0700
commitaa09b7e0c12e8d7a5e098fa8a45015beb00f5c20 (patch)
tree8dab2a1deba2e5b400fe530036406893be3d39b2 /tools/perf/scripts/python/stackcollapse.py
parentf66738dccd235112888c5b078eaef80fc9c68cf8 (diff)
parent7d6d8f0c8b700c9493f2839abccb6d29028b4219 (diff)
Merge branch 'fix-oom-and-order-check-in-msg_zerocopy-selftest'
Zijian Zhang says: ==================== fix OOM and order check in msg_zerocopy selftest In selftests/net/msg_zerocopy.c, it has a while loop keeps calling sendmsg on a socket with MSG_ZEROCOPY flag, and it will recv the notifications until the socket is not writable. Typically, it will start the receiving process after around 30+ sendmsgs. However, as the introduction of commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"), the sender is always writable and does not get any chance to run recv notifications. The selftest always exits with OUT_OF_MEMORY because the memory used by opt_skb exceeds the net.core.optmem_max. Meanwhile, it could be set to a different value to trigger OOM on older kernels too. Thus, we introduce "cfg_notification_limit" to force sender to receive notifications after some number of sendmsgs. And, we find that when lock debugging is on, notifications may not come in order. Thus, we have order checking outputs managed by cfg_verbose, to avoid too many outputs in this case. ==================== Link: https://patch.msgid.link/20240701225349.3395580-1-zijianzhang@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions