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:
signature.asc
Description: This is a digitally signed message part
