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. -- Michal Hocko SUSE Labs
