From: Andrew Morton <akpm@linux-foundation.org>
To: Roman Gushchin <guro@fb.com>
Cc: Tejun Heo <tj@kernel.org>, <linux-fsdevel@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Dennis Zhou <dennis@kernel.org>,
Dave Chinner <dchinner@redhat.com>, <cgroups@vger.kernel.org>
Subject: Re: [PATCH v9 8/8] writeback, cgroup: release dying cgwbs by switching attached inodes
Date: Tue, 8 Jun 2021 17:12:37 -0700 [thread overview]
Message-ID: <20210608171237.be2f4223de89458841c10fd4@linux-foundation.org> (raw)
In-Reply-To: <20210608230225.2078447-9-guro@fb.com>
On Tue, 8 Jun 2021 16:02:25 -0700 Roman Gushchin <guro@fb.com> wrote:
> Asynchronously try to release dying cgwbs by switching attached inodes
> to the nearest living ancestor wb. It helps to get rid of per-cgroup
> writeback structures themselves and of pinned memory and block cgroups,
> which are significantly larger structures (mostly due to large per-cpu
> statistics data). This prevents memory waste and helps to avoid
> different scalability problems caused by large piles of dying cgroups.
>
> Reuse the existing mechanism of inode switching used for foreign inode
> detection. To speed things up batch up to 115 inode switching in a
> single operation (the maximum number is selected so that the resulting
> struct inode_switch_wbs_context can fit into 1024 bytes). Because
> every switching consists of two steps divided by an RCU grace period,
> it would be too slow without batching. Please note that the whole
> batch counts as a single operation (when increasing/decreasing
> isw_nr_in_flight). This allows to keep umounting working (flush the
> switching queue), however prevents cleanups from consuming the whole
> switching quota and effectively blocking the frn switching.
>
> A cgwb cleanup operation can fail due to different reasons (e.g. not
> enough memory, the cgwb has an in-flight/pending io, an attached inode
> in a wrong state, etc). In this case the next scheduled cleanup will
> make a new attempt. An attempt is made each time a new cgwb is offlined
> (in other words a memcg and/or a blkcg is deleted by a user). In the
> future an additional attempt scheduled by a timer can be implemented.
>
> ...
>
> +/*
> + * Maximum inodes per isw. A specific value has been chosen to make
> + * struct inode_switch_wbs_context fit into 1024 bytes kmalloc.
> + */
> +#define WB_MAX_INODES_PER_ISW 115
Can't we do 1024/sizeof(struct inode_switch_wbs_context)?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
Dennis Zhou <dennis-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Dave Chinner <dchinner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v9 8/8] writeback, cgroup: release dying cgwbs by switching attached inodes
Date: Tue, 8 Jun 2021 17:12:37 -0700 [thread overview]
Message-ID: <20210608171237.be2f4223de89458841c10fd4@linux-foundation.org> (raw)
In-Reply-To: <20210608230225.2078447-9-guro-b10kYP2dOMg@public.gmane.org>
On Tue, 8 Jun 2021 16:02:25 -0700 Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org> wrote:
> Asynchronously try to release dying cgwbs by switching attached inodes
> to the nearest living ancestor wb. It helps to get rid of per-cgroup
> writeback structures themselves and of pinned memory and block cgroups,
> which are significantly larger structures (mostly due to large per-cpu
> statistics data). This prevents memory waste and helps to avoid
> different scalability problems caused by large piles of dying cgroups.
>
> Reuse the existing mechanism of inode switching used for foreign inode
> detection. To speed things up batch up to 115 inode switching in a
> single operation (the maximum number is selected so that the resulting
> struct inode_switch_wbs_context can fit into 1024 bytes). Because
> every switching consists of two steps divided by an RCU grace period,
> it would be too slow without batching. Please note that the whole
> batch counts as a single operation (when increasing/decreasing
> isw_nr_in_flight). This allows to keep umounting working (flush the
> switching queue), however prevents cleanups from consuming the whole
> switching quota and effectively blocking the frn switching.
>
> A cgwb cleanup operation can fail due to different reasons (e.g. not
> enough memory, the cgwb has an in-flight/pending io, an attached inode
> in a wrong state, etc). In this case the next scheduled cleanup will
> make a new attempt. An attempt is made each time a new cgwb is offlined
> (in other words a memcg and/or a blkcg is deleted by a user). In the
> future an additional attempt scheduled by a timer can be implemented.
>
> ...
>
> +/*
> + * Maximum inodes per isw. A specific value has been chosen to make
> + * struct inode_switch_wbs_context fit into 1024 bytes kmalloc.
> + */
> +#define WB_MAX_INODES_PER_ISW 115
Can't we do 1024/sizeof(struct inode_switch_wbs_context)?
next prev parent reply other threads:[~2021-06-09 0:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 23:02 [PATCH v9 0/8] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 1/8] writeback, cgroup: do not switch inodes with I_WILL_FREE flag Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 2/8] writeback, cgroup: add smp_mb() to cgroup_writeback_umount() Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 3/8] writeback, cgroup: increment isw_nr_in_flight before grabbing an inode Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-09 3:32 ` Ming Lei
2021-06-10 0:21 ` Roman Gushchin
2021-06-10 0:21 ` Roman Gushchin
2021-06-10 6:57 ` Ming Lei
2021-06-10 6:57 ` Ming Lei
2021-06-08 23:02 ` [PATCH v9 4/8] writeback, cgroup: switch to rcu_work API in inode_switch_wbs() Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 5/8] writeback, cgroup: keep list of inodes attached to bdi_writeback Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 6/8] writeback, cgroup: split out the functional part of inode_switch_wbs_work_fn() Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 7/8] writeback, cgroup: support switching multiple inodes at once Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-08 23:02 ` [PATCH v9 8/8] writeback, cgroup: release dying cgwbs by switching attached inodes Roman Gushchin
2021-06-08 23:02 ` Roman Gushchin
2021-06-09 0:12 ` Andrew Morton [this message]
2021-06-09 0:12 ` Andrew Morton
2021-06-09 0:23 ` Roman Gushchin
2021-06-09 0:23 ` Roman Gushchin
2021-06-09 0:37 ` Dennis Zhou
2021-06-09 0:37 ` Dennis Zhou
2021-06-09 5:34 ` Andrew Morton
2021-06-09 5:34 ` Andrew Morton
2021-06-09 19:53 ` Roman Gushchin
2021-06-09 19:53 ` 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=20210608171237.be2f4223de89458841c10fd4@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=dchinner@redhat.com \
--cc=dennis@kernel.org \
--cc=guro@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=viro@zeniv.linux.org.uk \
/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.