Re: [LSF/MM TOPIC] dying memory cgroups and slab reclaim issues

[Rik van Riel <riel@surriel.com>]

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

On Wed, 2019-02-20 at 15:33 +1100, Dave Chinner wrote:
> On Tue, Feb 19, 2019 at 09:06:07PM -0500, Rik van Riel wrote:
> > 
> > You are overlooking the fact that an inode loaded
> > into memory by one cgroup (which is getting torn
> > down) may be in active use by processes in other
> > cgroups.
> 
> No I am not. I am fully aware of this problem (have been since memcg
> day one because of the list_lru tracking issues Glauba and I had to
> sort out when we first realised shared inodes could occur). Sharing
> inodes across cgroups also causes "complexity" in things like cgroup
> writeback control (which cgroup dirty list tracks and does writeback
> of shared inodes?) and so on. Shared inodes across cgroups are
> considered the exception rather than the rule, and they are treated
> in many places with algorithms that assert "this is rare, if it's
> common we're going to be in trouble"....

It is extremely common to have files used from
multiple cgroups. For example:
- The main workload generates a log file, which
  is parsed from a (lower priority) system cgroup.
- A backup program reads files that are also accessed
  by the main workload.
- Systemd restarts a program that runs in a cgroup,
  into a new cgroup. This ends up touching many/most of 
  the same files that were in use in the old instance 
  of the program, running in the old cgroup.

With cgroup use being largely automated, instead of
set up manually, it is becoming more and more common
to see systems where dozens of cgroups are created
and torn down daily.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]