On 25 October 2017 at 01:06, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > [ 3551.169126] chrome: page allocation stalls for 11542ms, order:0, > > mode:0x14280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), nodemask=(null) > > this is a sleeping allocation which means that it is allowed to perform > the direct reclaim and that took a lot of time here. This is really > unusual and worth debugging some more. > > [...] > > [ 3551.169590] Mem-Info: > > [ 3551.169595] active_anon:6904352 inactive_anon:520427 isolated_anon:0 > > active_file:55480 inactive_file:38890 isolated_file:0 > > unevictable:1836 dirty:556 writeback:0 unstable:0 > > slab_reclaimable:67559 slab_unreclaimable:95967 > > mapped:353547 shmem:480723 pagetables:89161 bounce:0 > > free:49404 free_pcp:1474 free_cma:0 > > This tells us that there is quite some page cache (file LRUs) to reclaim > so I am wondering what could have caused such a delay. In order to debug > this some more we would need an additional debugging information. I > usually enable vmscan tracepoints to watch for events during the > reclaim. > I able got the needed tracepoints logs. If I understanded correctly vmscan tracepoints are possible enable by option 1 in the file /sys/kernel/debug/tracing/events/vmscan/enable All archives attached to this email. -- Best Regards, Mike Gavrilov.
Attachment:
dmesg.tar.xz
Description: application/xz
Attachment:
trace.tar.xz
Description: application/xz
