Am 09.09.19 um 14:28 schrieb Michal Hocko: > On Mon 09-09-19 14:10:02, Stefan Priebe - Profihost AG wrote: >> >> Am 09.09.19 um 14:08 schrieb Michal Hocko: >>> On Mon 09-09-19 13:01:36, Michal Hocko wrote: >>>> and that matches moments when we reclaimed memory. There seems to be a >>>> steady THP allocations flow so maybe this is a source of the direct >>>> reclaim? >>> >>> I was thinking about this some more and THP being a source of reclaim >>> sounds quite unlikely. At least in a default configuration because we >>> shouldn't do anything expensinve in the #PF path. But there might be a >>> difference source of high order (!costly) allocations. Could you check >>> how many allocation requests like that you have on your system? >>> >>> mount -t debugfs none /debug >>> echo "order > 0" > /debug/tracing/events/kmem/mm_page_alloc/filter >>> echo 1 > /debug/tracing/events/kmem/mm_page_alloc/enable >>> cat /debug/tracing/trace_pipe > $file > > echo 1 > /debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_begin/enable > echo 1 > /debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_end/enable > > might tell us something as well but it might turn out that it just still > doesn't give us the full picture and we might need > echo stacktrace > /debug/tracing/trace_options > > It will generate much more output though. > >> Just now or when PSI raises? > > When the excessive reclaim is happening ideally. This one is from a server with 28G memfree but memory pressure is still jumping between 0 and 10%. I did: echo "order > 0" > /sys/kernel/debug/tracing/events/kmem/mm_page_alloc/filter echo 1 > /sys/kernel/debug/tracing/events/kmem/mm_page_alloc/enable echo 1 > /sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_begin/enable echo 1 > /sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_end/enable timeout 120 cat /sys/kernel/debug/tracing/trace_pipe > /trace File attached. Stefan
Attachment:
trace.gz
Description: application/gzip
