On 26 October 2017 at 22:49, Михаил Гаврилов <mikhail.v.gavrilov@xxxxxxxxx> wrote: > 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. > I was able to catch this issue again. Is there anything interesting in the trace logs? -- Best Regards, Mike Gavrilov.
Attachment:
dmesg22.tar.xz
Description: application/xz
Attachment:
trace22.tar.xz
Description: application/xz
