mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: lizefan@huawei.com, hannes@cmpxchg.org, bsingharora@gmail.com,
	kamezawa.hiroyu@jp.fujitsu.com,
	containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create()
Date: Thu, 1 Nov 2012 16:05:32 +0100	[thread overview]
Message-ID: <20121101150532.GA5065@dhcp22.suse.cz> (raw)
In-Reply-To: <CAOS58YM+kRtspVUzmnSmOmrDoNS_kF6KA02zWGxqH5FUcRWo1Q@mail.gmail.com>

On Thu 01-11-12 07:52:24, Tejun Heo wrote:
> Hey, Michal.
> 
> On Thu, Nov 1, 2012 at 2:16 AM, Michal Hocko <mhocko@suse.cz> wrote:
> > I am not sure I understand. What does deactivate_super has to do with
> > the above suggestion? cgroup_lock_live_group will take the cgroup_mutex
> > on the success or frees the previously allocated&unused memory. The
> > only thing I was suggesting is to do cgroup_lock_live_group first and
> > allocate the cgroup only if it doesn't fail.
> 
> It complicates updates to the error exit path.

Still don't get it, sorry. What prevents us to do:
static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
                             umode_t mode)
{
        struct cgroup *cgrp;
        struct cgroupfs_root *root = parent->root;
        int err = 0;
        struct cgroup_subsys *ss;
        struct super_block *sb = root->sb;

	if (!cgroup_lock_live_group(parent))
		return -ENODEV;

        cgrp = kzalloc(sizeof(*cgrp), GFP_KERNEL);
        if (!cgrp)
                return -ENOMEM;

> You end up having to update a lot more and it's not like grabbing lock
> first is substantially better in any way, so why bother?

Yes the allocation can sleep if we are short on memory so this can
potentially take long which is not entirely nice but a pointless
allocation is not nice either. Anyway I am asking because I am trying to
understand what is the motivation behind and your explanation about the
error exit path doesn't make much sense to me. So I am either missing
something or we are talking about two different things.
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2012-11-01 15:05 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31  4:22 [PATCHSET] cgroup: simplify cgroup removal path Tejun Heo
2012-10-31  4:22 ` [PATCH 1/8] cgroup: kill cgroup_subsys->__DEPRECATED_clear_css_refs Tejun Heo
2012-10-31 13:21   ` Glauber Costa
2012-10-31 16:38     ` Tejun Heo
2012-10-31 14:37   ` Michal Hocko
2012-10-31 16:41     ` Tejun Heo
2012-10-31 16:48       ` Michal Hocko
2012-10-31 17:22         ` Tejun Heo
2012-11-02  9:23   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 2/8] cgroup: kill CSS_REMOVED Tejun Heo
2012-10-31 15:39   ` Michal Hocko
2012-10-31 16:57     ` Tejun Heo
2012-10-31 17:06       ` Glauber Costa
2012-10-31 17:10         ` Tejun Heo
2012-10-31 17:19           ` Glauber Costa
2012-10-31 17:25             ` Tejun Heo
2012-10-31 17:38               ` Glauber Costa
2012-10-31 17:44                 ` Tejun Heo
2012-10-31 17:39               ` Glauber Costa
2012-10-31 19:16       ` Michal Hocko
2012-10-31 19:33         ` Tejun Heo
2012-11-02  9:30   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 3/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create() Tejun Heo
2012-10-31 15:55   ` Michal Hocko
2012-10-31 17:04     ` Tejun Heo
2012-11-01  9:16       ` Michal Hocko
2012-11-01 14:52         ` Tejun Heo
2012-11-01 15:05           ` Michal Hocko [this message]
2012-11-01 15:15             ` Michal Hocko
2012-11-01 15:43               ` Tejun Heo
2012-11-02  9:37   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 4/8] cgroup: deactivate CSS's and mark cgroup dead before invoking ->pre_destroy() Tejun Heo
2012-10-31 13:42   ` Glauber Costa
2012-10-31 16:05   ` Michal Hocko
2012-11-02  9:43   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 5/8] cgroup: remove CGRP_WAIT_ON_RMDIR, cgroup_exclude_rmdir() and cgroup_release_and_wakeup_rmdir() Tejun Heo
2012-10-31 16:27   ` Michal Hocko
2012-10-31 17:16     ` Tejun Heo
2012-11-02  9:53   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 6/8] memcg: make mem_cgroup_reparent_charges non failing Tejun Heo
2012-11-02  9:54   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 7/8] hugetlb: do not fail in hugetlb_cgroup_pre_destroy Tejun Heo
2012-11-02  9:56   ` Kamezawa Hiroyuki
2012-10-31  4:22 ` [PATCH 8/8] cgroup: make ->pre_destroy() return void Tejun Heo
2012-10-31 13:57   ` Vivek Goyal
2012-10-31 16:28   ` Michal Hocko
2012-11-02  9:57   ` Kamezawa Hiroyuki
2012-10-31 13:49 ` [PATCHSET] cgroup: simplify cgroup removal path Glauber Costa
2012-10-31 17:18   ` Tejun Heo
2012-10-31 17:24     ` Glauber Costa
2012-10-31 17:26       ` Tejun Heo
2012-10-31 17:33         ` Glauber Costa
2012-10-31 16:31 ` Michal Hocko
2012-10-31 16:35   ` Tejun Heo
2012-10-31 18:16 [PATCHSET v2] " Tejun Heo
2012-10-31 18:16 ` [PATCH 3/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create() Tejun Heo
2012-10-31 19:44 [PATCHSET RESEND v2] cgroup: simplify cgroup removal path Tejun Heo
2012-10-31 19:44 ` [PATCH 3/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create() Tejun Heo
2012-11-02 10:03   ` Kamezawa Hiroyuki
2012-11-05  5:36   ` Li Zefan

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=20121101150532.GA5065@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=bsingharora@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --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

Powered by JetHome