From: Li Zefan <lizf@cn•fujitsu.com>
To: Paul Menage <menage@google•com>
Cc: Grzegorz Nosek <root@localdomain•pl>,
containers@lists•osdl.org, netdev@vger•kernel.org
Subject: Re: [Devel] Re: [RFC][PATCH] IP address restricting cgroup subsystem
Date: Wed, 14 Jan 2009 10:47:42 +0800 [thread overview]
Message-ID: <496D524E.6050706@cn.fujitsu.com> (raw)
In-Reply-To: <6599ad830901131807n3acf6936g2028fc5f7edd6264@mail.gmail.com>
> That would be possible, but I'm not sure that extending
> hierarchy_mutex across all the create calls is a good idea - it's
> meant to be very lightweight.
>
agree
> OK, an alternative way to avoid cgroup_lock() is for the
> spinlock-protected state in ipcgroup to be the address and the count
> of active children.
>
This works. But:
- we put extra burden on subsystem developers.
- hierarchy_mutex can't do what we expect, and it's a bit subtle.
- there won't be performance problem or potential lock issue to use
cgroup_mutex in subsys' simple write functions, so I don't think
we have to avoid cgroup_mutex here.
In memcg, both mem_cgroup_hierarchy_write() and mem_cgroup_swappiness_write()
check cgrp->children list, similar to ipv4_write() here. And I'm going
to fix swappiness_write() for it doesn't hold cgroup_lock(), but if
avoiding cgroup_lock() is the direction, then I have to use this
alternative way you sugguested.
> create() does:
>
> lock parent
> css->addr = parent->addr
> parent->child_count++;
> unlock parent
>
> and write does:
>
> lock css
> if (!css->child_count) {
> css->addr = new_addr
> } else {
> report error;
> }
> unlock css
>
> Paul
>
>
next prev parent reply other threads:[~2009-01-14 2:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090106230554.GB25228@eskarina.localdomain.pl>
[not found] ` <20090106230554.GB25228-IaEwMO9oKu/77SC2UrCW1JJg/dWx8T/9@public.gmane.org>
2009-01-07 6:01 ` [RFC][PATCH] IP address restricting cgroup subsystem Li Zefan
[not found] ` <49644526.8030205-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-01-07 7:38 ` Grzegorz Nosek
2009-01-07 8:36 ` Li Zefan
2009-01-07 9:16 ` Grzegorz Nosek
2009-01-07 9:33 ` Li Zefan
2009-01-07 9:37 ` Grzegorz Nosek
2009-01-09 21:38 ` [Devel] " Paul Menage
2009-01-10 4:50 ` Li Zefan
2009-01-10 16:14 ` Paul Menage
2009-01-12 2:20 ` Li Zefan
2009-01-14 2:07 ` Paul Menage
2009-01-14 2:47 ` Li Zefan [this message]
2009-01-14 2:50 ` Paul Menage
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=496D524E.6050706@cn.fujitsu.com \
--to=lizf@cn$(echo .)fujitsu.com \
--cc=containers@lists$(echo .)osdl.org \
--cc=menage@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=root@localdomain$(echo .)pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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