linux-kernel - Re: [PATCH v2 6/6] blkcg, memcg: make blkcg depend on memcg on the default hierarchy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20140709115746.GA26504@redhat.com>
Date:	Wed, 9 Jul 2014 07:57:46 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	lizefan@...wei.com, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, hannes@...xchg.org, mhocko@...e.cz,
	axboe@...nel.dk
Subject: Re: [PATCH v2 6/6] blkcg, memcg: make blkcg depend on memcg on the
 default hierarchy

On Tue, Jul 08, 2014 at 05:53:51PM -0400, Tejun Heo wrote:
> Hello, Vivek.
> 
> On Tue, Jul 08, 2014 at 03:42:26PM -0400, Vivek Goyal wrote:
> > I have couple questions about new semantics. Following is my
> > understanding. Is it right?
> > 
> > - So after this change one can not use blkio controller on unified
> >   hiearchy if memory controller is mounted on some other hierarchy
> >   and is not available for mounting unified hiearchy.
> 
> Hmmm?  No, the only behavior which changes is when both blkcg and
> memcg are mounted on the unified hierarchy.  Nothing else changes.
> The dependency behavior kicks in iff memcg is available on the unified
> hierarchy.

Ok, good to know that dependency kicks in only if controlle being depended
on is available on the hierarchy.
> 
> > - If blkio controller is enabled on unified hiearchy (memory controller
> >   implicitly enabled), then one can't mount memory controller on other
> >   hierarchies without first disabling blkio controller on unified hiearchy.
> 
> Yes, blkio needs to be disabled to the root for memcg to be able to
> become free.  This is an extra restriction but I don't think it's
> anything drastic.  Once a controller starts being actively used on any
> hierarchy, nothing has been guaranteed about when the controller would
> become free again even if the whole hierarchy is reduced to the root.

Agreed. Thanks for the clarification.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/