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: 1662 bytes --]

On 26 October 2017 at 22:49, Михаил Гаврилов
<mikhail.v.gavrilov@gmail.com> wrote:
> 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.
>

I was able to catch this issue again.
Is there anything interesting in the trace logs?

--
Best Regards,
Mike Gavrilov.

[-- Attachment #2: dmesg22.tar.xz --]
[-- Type: application/x-xz, Size: 23228 bytes --]

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