From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCHSET v2 cgroup/for-3.15] cgroup: update task migration path
Date: Tue, 25 Feb 2014 16:56:40 +0800 [thread overview]
Message-ID: <530C5AC8.5070806@huawei.com> (raw)
In-Reply-To: <1392323333-18907-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 2014/2/14 4:28, Tejun Heo wrote:
> Hello,
>
> This is v2 of update-task-migration-path patchset. Changes from v1[L]
> are
>
> * Rebased on top of "[PATCH cgroup/for-3.14-fixes] cgroup: update
> cgroup_enable_task_cg_lists() to grab siglock"
>
> * 0005-cgroup-update-how-a-newly-forked-task-gets-associate.patch and
> 0006-cgroup-drop-task_lock-protection-around-task-cgroups.patch
> added to address the race between migration and fork paths.
>
> Currently, when migrating a task or process from one cgroup to
> another, a flex_array is used to keep track of the target tasks and
> associated css_sets. The current implementation has several issues.
>
> * flex_array size is limited. Given the current data structure, the
> limit is ~87k on 64bit, which is pretty high but not impossible to
> hit.
>
> * If multiple targets are being migrated, as migrating each target
> involves memory allocation, it can fail at any point. cgroup core
> doesn't keep track of enough state to roll back partial migration
> either, so it ends up aborting with some targets migrated with no
> way of finding out which. While this isn't a big issue now, we're
> gonna be making more use of multi-target migration.
>
> * Fork path could race against migration path and it was impossible to
> implement a mechanism to migrate all tasks of a cgroup to another
> because migration path can't tell whether there are just forked
> tasks pointing to the css_set but not linked yet.
>
> This patchset updates task migration path such that
>
> * task->cg_list and css_sets are also used to keep track of targets
> during migration so that no extra memory allocation is necessary to
> keep track of migration targets.
>
> * Migration is split into several stages so that all preparations
> which may fail can be performed for all targets before actually
> starting migrating tasks. Ignoring ->can_attach() failure, this can
> guarantee all-or-nothing semantics of multi-target migration.
>
> * Newly forked tasks are now atomically associated with and linked to
> the parent's css_set in cgroup_post_fork(). This guarantees that
> the new task either is visible in the source cgroup once the
> parent's migration is complete or ends up in the target cgroup in
> the first place. This means that just keeping moving tasks out of a
> cgroup until it's empty is guaranteed to migrate all tasks.
>
> This patchset contains the following seven patches.
>
> 0001-cgroup-add-css_set-mg_tasks.patch
> 0002-cgroup-use-css_set-mg_tasks-to-track-target-tasks-du.patch
> 0003-cgroup-separate-out-cset_group_from_root-from-task_c.patch
> 0004-cgroup-split-process-task-migration-into-four-steps.patch
> 0005-cgroup-update-how-a-newly-forked-task-gets-associate.patch
> 0006-cgroup-drop-task_lock-protection-around-task-cgroups.patch
> 0007-cgroup-update-cgroup_transfer_tasks-to-either-succee.patch
>
Acked-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Tejun Heo <tj@kernel.org>
Cc: <containers@lists.linux-foundation.org>,
<cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHSET v2 cgroup/for-3.15] cgroup: update task migration path
Date: Tue, 25 Feb 2014 16:56:40 +0800 [thread overview]
Message-ID: <530C5AC8.5070806@huawei.com> (raw)
In-Reply-To: <1392323333-18907-1-git-send-email-tj@kernel.org>
On 2014/2/14 4:28, Tejun Heo wrote:
> Hello,
>
> This is v2 of update-task-migration-path patchset. Changes from v1[L]
> are
>
> * Rebased on top of "[PATCH cgroup/for-3.14-fixes] cgroup: update
> cgroup_enable_task_cg_lists() to grab siglock"
>
> * 0005-cgroup-update-how-a-newly-forked-task-gets-associate.patch and
> 0006-cgroup-drop-task_lock-protection-around-task-cgroups.patch
> added to address the race between migration and fork paths.
>
> Currently, when migrating a task or process from one cgroup to
> another, a flex_array is used to keep track of the target tasks and
> associated css_sets. The current implementation has several issues.
>
> * flex_array size is limited. Given the current data structure, the
> limit is ~87k on 64bit, which is pretty high but not impossible to
> hit.
>
> * If multiple targets are being migrated, as migrating each target
> involves memory allocation, it can fail at any point. cgroup core
> doesn't keep track of enough state to roll back partial migration
> either, so it ends up aborting with some targets migrated with no
> way of finding out which. While this isn't a big issue now, we're
> gonna be making more use of multi-target migration.
>
> * Fork path could race against migration path and it was impossible to
> implement a mechanism to migrate all tasks of a cgroup to another
> because migration path can't tell whether there are just forked
> tasks pointing to the css_set but not linked yet.
>
> This patchset updates task migration path such that
>
> * task->cg_list and css_sets are also used to keep track of targets
> during migration so that no extra memory allocation is necessary to
> keep track of migration targets.
>
> * Migration is split into several stages so that all preparations
> which may fail can be performed for all targets before actually
> starting migrating tasks. Ignoring ->can_attach() failure, this can
> guarantee all-or-nothing semantics of multi-target migration.
>
> * Newly forked tasks are now atomically associated with and linked to
> the parent's css_set in cgroup_post_fork(). This guarantees that
> the new task either is visible in the source cgroup once the
> parent's migration is complete or ends up in the target cgroup in
> the first place. This means that just keeping moving tasks out of a
> cgroup until it's empty is guaranteed to migrate all tasks.
>
> This patchset contains the following seven patches.
>
> 0001-cgroup-add-css_set-mg_tasks.patch
> 0002-cgroup-use-css_set-mg_tasks-to-track-target-tasks-du.patch
> 0003-cgroup-separate-out-cset_group_from_root-from-task_c.patch
> 0004-cgroup-split-process-task-migration-into-four-steps.patch
> 0005-cgroup-update-how-a-newly-forked-task-gets-associate.patch
> 0006-cgroup-drop-task_lock-protection-around-task-cgroups.patch
> 0007-cgroup-update-cgroup_transfer_tasks-to-either-succee.patch
>
Acked-by: Li Zefan <lizefan@huawei.com>
next prev parent reply other threads:[~2014-02-25 8:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 20:28 [PATCHSET v2 cgroup/for-3.15] cgroup: update task migration path Tejun Heo
2014-02-13 20:28 ` Tejun Heo
[not found] ` <1392323333-18907-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-02-13 20:28 ` [PATCH 1/7] cgroup: add css_set->mg_tasks Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 2/7] cgroup: use css_set->mg_tasks to track target tasks during migration Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 3/7] cgroup: separate out cset_group_from_root() from task_cgroup_from_root() Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 4/7] cgroup: split process / task migration into four steps Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 5/7] cgroup: update how a newly forked task gets associated with css_set Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 6/7] cgroup: drop task_lock() protection around task->cgroups Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-13 20:28 ` [PATCH 7/7] cgroup: update cgroup_transfer_tasks() to either succeed or fail Tejun Heo
2014-02-13 20:28 ` Tejun Heo
2014-02-25 8:56 ` Li Zefan [this message]
2014-02-25 8:56 ` [PATCHSET v2 cgroup/for-3.15] cgroup: update task migration path Li Zefan
2014-02-25 15:05 ` Tejun Heo
2014-02-25 15:05 ` Tejun Heo
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=530C5AC8.5070806@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 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.