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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120412123256.GI1787@cmpxchg.org>
Date:	Thu, 12 Apr 2012 14:32:56 +0200
From:	Johannes Weiner <hannes@...xchg.org>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg

On Thu, Apr 12, 2012 at 08:43:02AM -0300, Glauber Costa wrote:
> On 04/12/2012 08:32 AM, Frederic Weisbecker wrote:
> >>But I think increasing number of subsystem is not very good....
> >If the result is a better granularity on the overhead, I believe this
> >can be a good thing.
> 
> But again, since there is quite number of people trying to merge
> those stuff together, you are just swimming against the tide.

I don't see where merging unrelated controllers together is being
discussed, do you have a reference?

> If this gets really integrated, out of a sudden the overhead will
> appear. So better care about it now.

Forcing people that want to account/limit one resource to take the hit
for something else they are not interested in requires justification.
You can optimize only so much, in the end, the hierarchical accounting
is just expensive and unacceptable if you don't care about a certain
resource.  For that reason, I think controllers should stay opt-in.

Btw, can we please have a discussion where raised concerns are
supported by more than gut feeling?  "I think X is not very good" is
hardly an argument.  Where is the technical problem in increasing the
number of available controllers?
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ