Re: swapper/0: page allocation failure: order:0, mode:0x1204010(GFP_NOWAIT|__GFP_COMP|__GFP_RECLAIMABLE|__GFP_NOTRACK), nodemask=(null)

["Михаил Гаврилов" <mikhail.v.gavrilov@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On 25 October 2017 at 01:06, Michal Hocko <mhocko@kernel.org> 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 #2: dmesg.tar.xz --]
[-- Type: application/x-xz, Size: 23744 bytes --]

[-- Attachment #3: trace.tar.xz --]
[-- Type: application/x-xz, Size: 2183856 bytes --]