linux-kernel - Re: rsync: page allocation stalls in kernel 4.9.10 to a VessRAID NAS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20170301191942.GC24905@dhcp22.suse.cz>
Date:   Wed, 1 Mar 2017 20:19:43 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Robert Kudyba <rkudyba@...dham.edu>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: rsync: page allocation stalls in kernel 4.9.10 to a VessRAID NAS

On Wed 01-03-17 13:06:57, Robert Kudyba wrote:
[...]
> Does this ever finish?

Once there is no memory pressure

> The output file seems to grow really quickly. Here are a few lines and
> I can upload the file somewhere if you think it’d be helpful:
[...]
>          kswapd0-52    [001] .... 90900.812734: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=32 nr_reclaimed=32 priority=12 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [001] .... 90900.813762: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=1 nr_reclaimed=0 priority=11 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [001] .... 90900.813928: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=32 nr_reclaimed=32 priority=11 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [001] .... 90900.814823: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=22 nr_reclaimed=22 priority=11 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [001] .... 90900.815514: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=3 nr_reclaimed=0 priority=10 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [001] .... 90900.815643: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=32 nr_reclaimed=32 priority=10 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC
>          kswapd0-52    [002] .... 91073.571793: mm_vmscan_lru_shrink_inactive: nid=0 nr_scanned=27 nr_reclaimed=27 priority=5 flags=RECLAIM_WB_FILE|RECLAIM_WB_ASYNC

all those are from the kswapd (background memory reclaim). Which means
that it doesn't catch any allocation which can stall for too long.
Anyway the above tracepoint show that we are able to make some progress
during the reclaim (nr_reclaimed > 0). So I suspect that this is indeed
a large lowmem pressure and I do not see what we can do about that...

> > The rest of the report is rather messed up but I assume that you simply
> > do not have contiguous memory in the lowmem. This surely sounds like a
> > 32b specific problem which is not reasonably fixable.
> 
> Messed up as in unreadable? 

yeah 2 reports interleaved.

-- 
Michal Hocko
SUSE Labs