From: Tejun Heo <tj@kernel.org> To: Michal Hocko <mhocko@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, Petr Mladek <pmladek@suse.com>, cgroups@vger.kernel.org, Cyril Hrubis <chrubis@suse.cz>, linux-kernel@vger.kernel.org Subject: Re: [BUG] cgroup/workques/fork: deadlock when moving cgroups Date: Fri, 15 Apr 2016 10:38:15 -0400 [thread overview] Message-ID: <20160415143815.GH12583@htj.duckdns.org> (raw) In-Reply-To: <20160415070601.GA32377@dhcp22.suse.cz> Hello, Michal. On Fri, Apr 15, 2016 at 09:06:01AM +0200, Michal Hocko wrote: > Tejun was proposing to do the migration async (move the whole > mem_cgroup_move_charge into the work item). This would solve the problem > of course. I haven't checked whether this would be safe but it at least > sounds doable (albeit far from trivial). It would also be a user visible > change because the new memcg will not contain the moved charges after we > return to user space. I think this would be acceptable but if somebody Not necessarily. The only thing necessary is flushing the work item after releasing locks but before returning to user. cpuset_post_attach_flush() does exactly the same thing. > really relies on the previous behavior I guess we can solve it with a > post_move cgroup callback which would be called from a lockless context. > > Anyway, before we go that way, can we at least consider the possibility > of removing the kworker creation dependency on the global rwsem? AFAIU > this locking was added because of the pid controller. Do we even care > about something as volatile as kworkers in the pid controller? It's not just pid controller and the global percpu locking has lower hotpath overhead. We can try to exclude kworkers out of the locking but that can get really nasty and there are already attempts to add cgroup support to workqueue. Will think more about it. For now tho, do you think making charge moving async would be difficult? Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Petr Mladek <pmladek-IBi9RG/b67k@public.gmane.org>, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [BUG] cgroup/workques/fork: deadlock when moving cgroups Date: Fri, 15 Apr 2016 10:38:15 -0400 [thread overview] Message-ID: <20160415143815.GH12583@htj.duckdns.org> (raw) In-Reply-To: <20160415070601.GA32377-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> Hello, Michal. On Fri, Apr 15, 2016 at 09:06:01AM +0200, Michal Hocko wrote: > Tejun was proposing to do the migration async (move the whole > mem_cgroup_move_charge into the work item). This would solve the problem > of course. I haven't checked whether this would be safe but it at least > sounds doable (albeit far from trivial). It would also be a user visible > change because the new memcg will not contain the moved charges after we > return to user space. I think this would be acceptable but if somebody Not necessarily. The only thing necessary is flushing the work item after releasing locks but before returning to user. cpuset_post_attach_flush() does exactly the same thing. > really relies on the previous behavior I guess we can solve it with a > post_move cgroup callback which would be called from a lockless context. > > Anyway, before we go that way, can we at least consider the possibility > of removing the kworker creation dependency on the global rwsem? AFAIU > this locking was added because of the pid controller. Do we even care > about something as volatile as kworkers in the pid controller? It's not just pid controller and the global percpu locking has lower hotpath overhead. We can try to exclude kworkers out of the locking but that can get really nasty and there are already attempts to add cgroup support to workqueue. Will think more about it. For now tho, do you think making charge moving async would be difficult? Thanks. -- tejun
next prev parent reply other threads:[~2016-04-15 14:38 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-13 9:42 [BUG] cgroup/workques/fork: deadlock when moving cgroups Petr Mladek 2016-04-13 18:33 ` Tejun Heo 2016-04-13 18:33 ` Tejun Heo 2016-04-13 18:57 ` Tejun Heo 2016-04-13 18:57 ` Tejun Heo 2016-04-13 19:23 ` Michal Hocko 2016-04-13 19:23 ` Michal Hocko 2016-04-13 19:28 ` Michal Hocko 2016-04-13 19:28 ` Michal Hocko 2016-04-13 19:37 ` Tejun Heo 2016-04-13 19:48 ` Michal Hocko 2016-04-14 7:06 ` Michal Hocko 2016-04-14 7:06 ` Michal Hocko 2016-04-14 15:32 ` Tejun Heo 2016-04-14 15:32 ` Tejun Heo 2016-04-14 17:50 ` Johannes Weiner 2016-04-15 7:06 ` Michal Hocko 2016-04-15 14:38 ` Tejun Heo [this message] 2016-04-15 14:38 ` Tejun Heo 2016-04-15 15:08 ` Michal Hocko 2016-04-15 15:08 ` Michal Hocko 2016-04-15 15:25 ` Tejun Heo 2016-04-15 15:25 ` Tejun Heo 2016-04-17 12:00 ` Michal Hocko 2016-04-17 12:00 ` Michal Hocko 2016-04-18 14:40 ` Petr Mladek 2016-04-18 14:40 ` Petr Mladek 2016-04-19 14:01 ` Michal Hocko 2016-04-19 14:01 ` Michal Hocko 2016-04-19 15:39 ` Petr Mladek 2016-04-15 19:17 ` [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge() Tejun Heo 2016-04-17 12:07 ` Michal Hocko 2016-04-17 12:07 ` Michal Hocko 2016-04-20 21:29 ` Tejun Heo 2016-04-20 21:29 ` Tejun Heo 2016-04-21 3:27 ` Michal Hocko 2016-04-21 3:27 ` Michal Hocko 2016-04-21 15:00 ` Petr Mladek 2016-04-21 15:00 ` Petr Mladek 2016-04-21 15:51 ` Tejun Heo 2016-04-21 23:06 ` [PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback Tejun Heo 2016-04-21 23:06 ` Tejun Heo 2016-04-21 23:09 ` [PATCH 2/2] memcg: relocate charge moving from ->attach to ->post_attach Tejun Heo 2016-04-21 23:09 ` Tejun Heo 2016-04-22 13:57 ` Petr Mladek 2016-04-22 13:57 ` Petr Mladek 2016-04-25 8:25 ` Michal Hocko 2016-04-25 8:25 ` Michal Hocko 2016-04-25 19:42 ` Tejun Heo 2016-04-25 19:42 ` Tejun Heo 2016-04-25 19:44 ` Tejun Heo 2016-04-25 19:44 ` Tejun Heo 2016-04-21 23:11 ` [PATCH 1/2] cgroup, cpuset: replace cpuset_post_attach_flush() with cgroup_subsys->post_attach callback Tejun Heo 2016-04-21 23:11 ` Tejun Heo 2016-04-21 15:56 ` [PATCH for-4.6-fixes] memcg: remove lru_add_drain_all() invocation from mem_cgroup_move_charge() Tejun Heo 2016-04-21 15:56 ` 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=20160415143815.GH12583@htj.duckdns.org \ --to=tj@kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=chrubis@suse.cz \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mhocko@kernel.org \ --cc=pmladek@suse.com \ /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: linkBe 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.