linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>, "tj@kernel.org" <tj@kernel.org>,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups
Date: Mon, 7 Oct 2019 23:35:43 +0000	[thread overview]
Message-ID: <20191007233539.GC11171@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <f12d0a39-b7ef-39f9-3ff7-412c2d36aaac@suse.cz>

On Mon, Oct 07, 2019 at 04:57:15PM +0200, Vlastimil Babka wrote:
> On 10/5/19 12:11 AM, Roman Gushchin wrote:
> >
> > One possible approach to this problem is to switch inodes associated
> > with dying wbs to the root wb. Switching is a best effort operation
> > which can fail silently, so unfortunately we can't run once over a
> > list of associated inodes (even if we'd have such a list). So we
> > really have to scan all inodes.
> > 
> > In the proposed patch I schedule a work on each memory cgroup
> > deletion, which is probably too often. Alternatively, we can do it
> > periodically under some conditions (e.g. the number of dying memory
> > cgroups is larger than X). So it's basically a gc run.
> > 
> > I wonder if there are any better ideas?
> 
> I don't know this area, so this will be likely easily shown impossible,
> but perhaps it's useful to do that explicitly.
> 
> What if instead of reparenting each inode, we "reparent" the wb?

It seems to be an arguable idea, at least at the offlining moment.
Dirty memory left after a cgroup should be written back using
corresponding limits, and reparenting can easily break them.

Also, it's not clear to me, how to reparent dirty stats?

> But I see it's not a small object either. Could we then add some bias
> for inode switching conditions so that anyone else touching the inode
> from dead wb would get it immediately?

You mean touching for writing? That's doable, but doesn't solve the case
when there are only readers. And the case is quite common.

> And what would happen if we reused the reparented wb's for newly created
> cgroups? Would it "punish" them for the old inodes?
> 

No idea, to be honest.

Thank you!


  reply	other threads:[~2019-10-07 23:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 22:11 [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups Roman Gushchin
2019-10-07 14:57 ` Vlastimil Babka
2019-10-07 23:35   ` Roman Gushchin [this message]
2019-10-07 16:19 ` Michal Koutný
2019-10-07 23:24   ` Roman Gushchin
2019-10-08  4:06 ` Dave Chinner
     [not found]   ` <20191008053854.GA14951@castle.dhcp.thefacebook.com>
2019-10-08  8:20     ` Jan Kara
2019-10-09  5:19       ` Roman Gushchin
2019-10-09 21:48       ` Roman Gushchin
2019-10-07  6:01 Hillf Danton
2019-10-07 22:02 ` Roman Gushchin

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=20191007233539.GC11171@tower.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).