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