On Fri, Sep 14, 2012 at 12:19:06PM +0400, Glauber Costa wrote:
> I want oppose it as well, but I believe part of this exercise is to make
> the need to have hierarchy widespread. Warning on the case
> 1st-level-only case helps with that, even if we make more noise than we
> should.
>
> The reason
On Fri, Sep 14, 2012 at 12:19:06PM +0400, Glauber Costa wrote:
I want oppose it as well, but I believe part of this exercise is to make
the need to have hierarchy widespread. Warning on the case
1st-level-only case helps with that, even if we make more noise than we
should.
The reason I
Hello, Daniel.
On Thu, Sep 13, 2012 at 01:16:29PM +0100, Daniel P. Berrange wrote:
> If you want application developers / users to understand this, then
> you really need to update the Documentation/cgroups/cgroups.txt file
> to provide suitable recommendations on use of hierarchies. As it
>
On Thu 13-09-12 10:18:32, Tejun Heo wrote:
> Hello, Michal.
>
> On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
> > I would like to see use_hierarchy go away. The only concern I have is
> > to warn only if somebody is doing something wrong (aka flat
> > hierarchies). Or better put
Hello, Glauber.
On Thu, Sep 13, 2012 at 04:01:40PM +0400, Glauber Costa wrote:
> This is getting confusing for me as well, because I don't know if your
> reply was targeted towards me or Michal. As for me, I am in agreement
> with what you did, and I merely replied to Michal's concern and
>
Hello, Michal.
On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
> I would like to see use_hierarchy go away. The only concern I have is
> to warn only if somebody is doing something wrong (aka flat
> hierarchies). Or better put it this way. Do not warn in cases which do
> not change
On Mon, Sep 10, 2012 at 03:33:55PM -0700, Tejun Heo wrote:
> (forgot cc'ing containers / cgroups mailing lists and used the old
> address for Li. Reposting. Sorry for the noise.)
>
> Currently, cgroup hierarchy support is a mess. cpu related subsystems
> behave correctly - configuration,
On Wed 12-09-12 10:11:20, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote:
> > > While I respect your goal of not warning about any configuration
> > > with max_level = 1, I believe the only sane configuration as soon
> > > as we get any 2nd-level child
On 2012/9/13 0:34, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 12, 2012 at 01:37:28PM +0400, Glauber Costa wrote:
>> "If a cpuset is cpu or mem exclusive, no other cpuset, other than
>> a direct ancestor or descendant, may share any of the same CPUs or
>> Memory Nodes."
>>
>> So I think it tricked
On 2012/9/13 0:34, Tejun Heo wrote:
Hello,
On Wed, Sep 12, 2012 at 01:37:28PM +0400, Glauber Costa wrote:
If a cpuset is cpu or mem exclusive, no other cpuset, other than
a direct ancestor or descendant, may share any of the same CPUs or
Memory Nodes.
So I think it tricked me as well. I
On Wed 12-09-12 10:11:20, Tejun Heo wrote:
Hello,
On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote:
While I respect your goal of not warning about any configuration
with max_level = 1, I believe the only sane configuration as soon
as we get any 2nd-level child is
On Mon, Sep 10, 2012 at 03:33:55PM -0700, Tejun Heo wrote:
(forgot cc'ing containers / cgroups mailing lists and used the old
address for Li. Reposting. Sorry for the noise.)
Currently, cgroup hierarchy support is a mess. cpu related subsystems
behave correctly - configuration,
Hello, Michal.
On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
I would like to see use_hierarchy go away. The only concern I have is
to warn only if somebody is doing something wrong (aka flat
hierarchies). Or better put it this way. Do not warn in cases which do
not change if
Hello, Glauber.
On Thu, Sep 13, 2012 at 04:01:40PM +0400, Glauber Costa wrote:
This is getting confusing for me as well, because I don't know if your
reply was targeted towards me or Michal. As for me, I am in agreement
with what you did, and I merely replied to Michal's concern and
On Thu 13-09-12 10:18:32, Tejun Heo wrote:
Hello, Michal.
On Thu, Sep 13, 2012 at 02:14:38PM +0200, Michal Hocko wrote:
I would like to see use_hierarchy go away. The only concern I have is
to warn only if somebody is doing something wrong (aka flat
hierarchies). Or better put it this
Hello, Daniel.
On Thu, Sep 13, 2012 at 01:16:29PM +0100, Daniel P. Berrange wrote:
If you want application developers / users to understand this, then
you really need to update the Documentation/cgroups/cgroups.txt file
to provide suitable recommendations on use of hierarchies. As it
stands
Hello,
On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote:
> > While I respect your goal of not warning about any configuration
> > with max_level = 1, I believe the only sane configuration as soon
> > as we get any 2nd-level child is use_hierarchy = 1 for everybody.
> >
> > Everything
Hello,
On Wed, Sep 12, 2012 at 05:47:45PM +0200, Michal Hocko wrote:
> > If it's absolutely necessary, I think it should be a root-only flag
> > (even if that ends up using the same code path). Eventually, we
> > really want to kill .use_hierarchy, or at least make it to RO 1. As
> > it's
Hello,
On Wed, Sep 12, 2012 at 01:37:28PM +0400, Glauber Costa wrote:
> "If a cpuset is cpu or mem exclusive, no other cpuset, other than
> a direct ancestor or descendant, may share any of the same CPUs or
> Memory Nodes."
>
> So I think it tricked me as well. I was under the impression that
>
On Wed 12-09-12 13:31:55, Glauber Costa wrote:
> On 09/11/2012 02:04 PM, Michal Hocko wrote:
> > I like the approach in general but see the comments bellow:
> >
> > On Mon 10-09-12 15:33:55, Tejun Heo wrote:
> > [...]
> >> --- a/mm/memcontrol.c
> >> +++ b/mm/memcontrol.c
> >> @@ -3855,12 +3855,17
On Tue 11-09-12 10:07:46, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Sep 11, 2012 at 12:04:33PM +0200, Michal Hocko wrote:
> > > cgroup_unlock();
> > > @@ -4953,6 +4958,7 @@ mem_cgroup_create(struct cgroup *cont)
> > > _cpu(memcg_stock, cpu);
> > >
On Tue 11-09-12 10:07:46, Tejun Heo wrote:
Hello, Michal.
On Tue, Sep 11, 2012 at 12:04:33PM +0200, Michal Hocko wrote:
cgroup_unlock();
@@ -4953,6 +4958,7 @@ mem_cgroup_create(struct cgroup *cont)
per_cpu(memcg_stock, cpu);
On Wed 12-09-12 13:31:55, Glauber Costa wrote:
On 09/11/2012 02:04 PM, Michal Hocko wrote:
I like the approach in general but see the comments bellow:
On Mon 10-09-12 15:33:55, Tejun Heo wrote:
[...]
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3855,12 +3855,17 @@ static int
Hello,
On Wed, Sep 12, 2012 at 01:37:28PM +0400, Glauber Costa wrote:
If a cpuset is cpu or mem exclusive, no other cpuset, other than
a direct ancestor or descendant, may share any of the same CPUs or
Memory Nodes.
So I think it tricked me as well. I was under the impression that
Hello,
On Wed, Sep 12, 2012 at 05:47:45PM +0200, Michal Hocko wrote:
If it's absolutely necessary, I think it should be a root-only flag
(even if that ends up using the same code path). Eventually, we
really want to kill .use_hierarchy, or at least make it to RO 1. As
it's currently
Hello,
On Wed, Sep 12, 2012 at 05:49:07PM +0200, Michal Hocko wrote:
While I respect your goal of not warning about any configuration
with max_level = 1, I believe the only sane configuration as soon
as we get any 2nd-level child is use_hierarchy = 1 for everybody.
Everything aside
Hello,
On Tue, Sep 11, 2012 at 10:08:37AM -0700, Tejun Heo wrote:
> > So isn't cpuset broken too? child cpuset's cpu mask isn't necessary a subset
> > of the parent's if the cpu_exclusive flag is not set.
>
> Heh, didn't even look at that. Just assumed it was in the same boat
> w/ cpu{acct}.
Hello, Li.
On Tue, Sep 11, 2012 at 08:38:51PM +0800, Li Zefan wrote:
> > (I tried to document what's broken and how it should be fixed. If I
> > got something wrong, please let me know.)
> >
>
> So isn't cpuset broken too? child cpuset's cpu mask isn't necessary a subset
> of the parent's if
Hello, Michal.
On Tue, Sep 11, 2012 at 12:04:33PM +0200, Michal Hocko wrote:
> > cgroup_unlock();
> > @@ -4953,6 +4958,7 @@ mem_cgroup_create(struct cgroup *cont)
> > _cpu(memcg_stock, cpu);
> > INIT_WORK(>work,
On 2012/9/11 6:33, Tejun Heo wrote:
> (forgot cc'ing containers / cgroups mailing lists and used the old
> address for Li. Reposting. Sorry for the noise.)
>
> Currently, cgroup hierarchy support is a mess. cpu related subsystems
> behave correctly - configuration, accounting and control on a
I like the approach in general but see the comments bellow:
On Mon 10-09-12 15:33:55, Tejun Heo wrote:
[...]
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3855,12 +3855,17 @@ static int mem_cgroup_hierarchy_write(st
>*/
> if ((!parent_memcg || !parent_memcg->use_hierarchy)
I like the approach in general but see the comments bellow:
On Mon 10-09-12 15:33:55, Tejun Heo wrote:
[...]
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3855,12 +3855,17 @@ static int mem_cgroup_hierarchy_write(st
*/
if ((!parent_memcg || !parent_memcg-use_hierarchy)
On 2012/9/11 6:33, Tejun Heo wrote:
(forgot cc'ing containers / cgroups mailing lists and used the old
address for Li. Reposting. Sorry for the noise.)
Currently, cgroup hierarchy support is a mess. cpu related subsystems
behave correctly - configuration, accounting and control on a
Hello, Michal.
On Tue, Sep 11, 2012 at 12:04:33PM +0200, Michal Hocko wrote:
cgroup_unlock();
@@ -4953,6 +4958,7 @@ mem_cgroup_create(struct cgroup *cont)
per_cpu(memcg_stock, cpu);
INIT_WORK(stock-work,
Hello, Li.
On Tue, Sep 11, 2012 at 08:38:51PM +0800, Li Zefan wrote:
(I tried to document what's broken and how it should be fixed. If I
got something wrong, please let me know.)
So isn't cpuset broken too? child cpuset's cpu mask isn't necessary a subset
of the parent's if the
Hello,
On Tue, Sep 11, 2012 at 10:08:37AM -0700, Tejun Heo wrote:
So isn't cpuset broken too? child cpuset's cpu mask isn't necessary a subset
of the parent's if the cpu_exclusive flag is not set.
Heh, didn't even look at that. Just assumed it was in the same boat
w/ cpu{acct}. Will
(forgot cc'ing containers / cgroups mailing lists and used the old
address for Li. Reposting. Sorry for the noise.)
Currently, cgroup hierarchy support is a mess. cpu related subsystems
behave correctly - configuration, accounting and control on a parent
properly cover its children. blkio
(forgot cc'ing containers / cgroups mailing lists and used the old
address for Li. Reposting. Sorry for the noise.)
Currently, cgroup hierarchy support is a mess. cpu related subsystems
behave correctly - configuration, accounting and control on a parent
properly cover its children. blkio
38 matches
Mail list logo
