linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Roman Gushchin <guro@fb.com>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, 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 16:57:15 +0200	[thread overview]
Message-ID: <f12d0a39-b7ef-39f9-3ff7-412c2d36aaac@suse.cz> (raw)
In-Reply-To: <20191004221104.646711-1-guro@fb.com>

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?
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?
And what would happen if we reused the reparented wb's for newly created
cgroups? Would it "punish" them for the old inodes?


  reply	other threads:[~2019-10-07 14:57 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 [this message]
2019-10-07 23:35   ` Roman Gushchin
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=f12d0a39-b7ef-39f9-3ff7-412c2d36aaac@suse.cz \
    --to=vbabka@suse.cz \
    --cc=guro@fb.com \
    --cc=jack@suse.cz \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tj@kernel.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 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).