From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Chris Down <chris@chrisdown.name>
Subject: Re: Memory CG and 5.1 to 5.6 uprade slows backup
Date: Fri, 10 Apr 2020 09:15:25 +0200 [thread overview]
Message-ID: <20200410091525.287062fa@hemera.lan.sysophe.eu> (raw)
In-Reply-To: <20200409152540.GP18386@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
Hi Michal,
On Thu, 9 Apr 2020 17:25:40 Michal Hocko <mhocko@kernel.org> wrote:
> Your earlier stat snapshot doesn't indicate a big problem with the
> reclaim though:
>
> memory.stat:pgscan 47519855
> memory.stat:pgsteal 44933838
>
> This tells the overall reclaim effectiveness was 94%. Could you try to
> gather snapshots with a 1s granularity starting before your run your
> backup to see how those numbers evolve? Ideally with timestamps to
> compare with the actual stall information.
Attached is a long collection of
date memory.current memory.stat[pgscan] memory.stat[pgsteal]
It started while backup was running +/- smoothly with its memory.high
set to 4294967296 (4G instead of 2G) until backup finished around 20:22.
From system memory pressure RRD-graph I see pressure (around 60)
between about 19:50 to 20:10 while very small the rest of the time
(below 1).
I started a new backup run this morning grabbing full info snapshots of
backup cgroup at 1s interval in order to get a better/more complete
picture and CG's memory.high back to 2G limit.
I have the impression as if reclaim was somehow triggered not enough or
not strongly enough compared to the IO performed within the CG
(complete backup covers 130G of data, data being read in blocks of
128kB at a smooth-running rate of ~7MiB/s).
> Another option would be to enable vmscan tracepoints but let's try with
> stats first.
Bruno
[-- Attachment #2: backup.cg_pg_.log.gz --]
[-- Type: application/gzip, Size: 123934 bytes --]
next prev parent reply other threads:[~2020-04-10 7:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 9:25 Bruno Prémont
2020-04-09 9:46 ` Michal Hocko
2020-04-09 10:17 ` Bruno Prémont
2020-04-09 10:34 ` Michal Hocko
2020-04-09 15:09 ` Bruno Prémont
2020-04-09 15:24 ` Chris Down
2020-04-09 15:40 ` Bruno Prémont
2020-04-09 17:50 ` Chris Down
2020-04-09 17:56 ` Chris Down
2020-04-09 15:25 ` Michal Hocko
2020-04-10 7:15 ` Bruno Prémont [this message]
2020-04-10 8:43 ` Bruno Prémont
[not found] ` <20200410115010.1d9f6a3f@hemera.lan.sysophe.eu>
[not found] ` <20200414163134.GQ4629@dhcp22.suse.cz>
2020-04-15 10:17 ` Bruno Prémont
2020-04-15 10:24 ` Michal Hocko
2020-04-15 11:37 ` Bruno Prémont
2020-04-14 15:09 ` Bruno Prémont
2020-04-09 10:50 ` Chris Down
2020-04-09 11:58 ` Bruno Prémont
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200410091525.287062fa@hemera.lan.sysophe.eu \
--to=bonbons@linux-vserver.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox