All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bruno Prémont" <bruno.premont-KvovOCrn0kWDPSPedkhhuQ@public.gmane.org>
To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
	Vladimir Davydov
	<vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Chris Down <chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
Subject: Re: Memory CG and 5.1 to 5.6 uprade slows backup
Date: Fri, 10 Apr 2020 10:43:43 +0200	[thread overview]
Message-ID: <20200410104343.5bcde519@hemera.lan.sysophe.eu> (raw)
In-Reply-To: <20200410091525.287062fa-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>

Hi Michal, Chris,

Well, tar made me unhappy, it just collected list of files but not
content from /sys/fs/cgroup/...

But if I set memory.max = memory.high reclaim seems to work and memory
pressure remains zero for the cg.
If I set memory.max = $((memory.high + 128M)) memory pressure rises
immediately (when memory.current ~= memory.high).

Returning to memory.max=memory.high gets things running again and
memory pressure starts dropping immediately.


Could it be that the wrong limit of high/max is being used for reclaim?


Bruno

On Fri, 10 Apr 2020 09:15:25 +0200
Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org> wrote:
> Hi Michal,
> 
> On Thu, 9 Apr 2020 17:25:40 Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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



-- 
Bruno Prémont <bruno.premont-KvovOCrn0kWDPSPedkhhuQ@public.gmane.org>
Ingénieur système et développements

Fondation RESTENA
2, avenue de l'Université
L-4365 Esch/Alzette

Tél: (+352) 424409
Fax: (+352) 422473
https://www.restena.lu     https://www.dns.lu

WARNING: multiple messages have this Message-ID (diff)
From: "Bruno Prémont" <bruno.premont@restena.lu>
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 10:43:43 +0200	[thread overview]
Message-ID: <20200410104343.5bcde519@hemera.lan.sysophe.eu> (raw)
In-Reply-To: <20200410091525.287062fa@hemera.lan.sysophe.eu>

Hi Michal, Chris,

Well, tar made me unhappy, it just collected list of files but not
content from /sys/fs/cgroup/...

But if I set memory.max = memory.high reclaim seems to work and memory
pressure remains zero for the cg.
If I set memory.max = $((memory.high + 128M)) memory pressure rises
immediately (when memory.current ~= memory.high).

Returning to memory.max=memory.high gets things running again and
memory pressure starts dropping immediately.


Could it be that the wrong limit of high/max is being used for reclaim?


Bruno

On Fri, 10 Apr 2020 09:15:25 +0200
Bruno Prémont <bonbons@linux-vserver.org> wrote:
> 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



-- 
Bruno Prémont <bruno.premont@restena.lu>
Ingénieur système et développements

Fondation RESTENA
2, avenue de l'Université
L-4365 Esch/Alzette

Tél: (+352) 424409
Fax: (+352) 422473
https://www.restena.lu     https://www.dns.lu


  parent reply	other threads:[~2020-04-10  8:43 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09  9:25 Memory CG and 5.1 to 5.6 uprade slows backup Bruno Prémont
2020-04-09  9:25 ` Bruno Prémont
     [not found] ` <20200409112505.2e1fc150-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-09  9:46   ` Michal Hocko
2020-04-09  9:46     ` Michal Hocko
     [not found]     ` <20200409094615.GE18386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-04-09 10:17       ` Bruno Prémont
2020-04-09 10:17         ` Bruno Prémont
     [not found]         ` <20200409121733.1a5ba17c-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-09 10:34           ` Michal Hocko
2020-04-09 10:34             ` Michal Hocko
     [not found]             ` <20200409103400.GF18386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-04-09 15:09               ` Bruno Prémont
2020-04-09 15:09                 ` Bruno Prémont
     [not found]                 ` <20200409170926.182354c3-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-09 15:24                   ` Chris Down
2020-04-09 15:24                     ` Chris Down
     [not found]                     ` <20200409152417.GB1040020-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-04-09 15:40                       ` Bruno Prémont
2020-04-09 15:40                         ` Bruno Prémont
     [not found]                         ` <20200409174042.2a3389ba-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-09 17:50                           ` Chris Down
2020-04-09 17:50                             ` Chris Down
     [not found]                             ` <20200409175044.GC1040020-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-04-09 17:56                               ` Chris Down
2020-04-09 17:56                                 ` Chris Down
2020-04-09 15:25                   ` Michal Hocko
2020-04-09 15:25                     ` Michal Hocko
2020-04-10  7:15                     ` Bruno Prémont
     [not found]                       ` <20200410091525.287062fa-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-10  8:43                         ` 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>
     [not found]                               ` <20200414163134.GQ4629-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-04-15 10:17                                 ` Bruno Prémont
2020-04-15 10:17                                   ` Bruno Prémont
     [not found]                                   ` <20200415121753.3c8d700b-pDZhbqX7CfkoGc32E1+a2S4z1YicLaQ4@public.gmane.org>
2020-04-15 10:24                                     ` Michal Hocko
2020-04-15 10:24                                       ` Michal Hocko
     [not found]                                       ` <20200415102442.GE4629-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-04-15 11:37                                         ` Bruno Prémont
2020-04-15 11:37                                           ` Bruno Prémont
     [not found]                     ` <20200409152540.GP18386-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-04-14 15:09                       ` Bruno Prémont
2020-04-14 15:09                         ` Bruno Prémont
2020-04-09 10:50   ` Chris Down
2020-04-09 10:50     ` Chris Down
     [not found]     ` <20200409105048.GA1040020-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org>
2020-04-09 11:58       ` Bruno Prémont
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=20200410104343.5bcde519@hemera.lan.sysophe.eu \
    --to=bruno.premont-kvovocrn0kwdpspedkhhuq@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=chris-6Bi1550iOqEnzZ6mRAm98g@public.gmane.org \
    --cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.