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]
Date:	Fri, 14 Sep 2012 11:33:16 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Li Zefan <lizefan@...wei.com>,
	Glauber Costa <glommer@...allels.com>,
	containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, Michal Hocko <mhocko@...e.cz>,
	Paul Turner <pjt@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Thomas Graf <tgraf@...g.ch>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Neil Horman <nhorman@...driver.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Lennart Poettering <lennart@...ttering.net>,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RFC] cgroup TODOs

Hello,

On Fri, Sep 14, 2012 at 08:23:41PM +0200, Peter Zijlstra wrote:
> Its hotplug, all hotplug stuff is synchronous, the last thing hotplug
> needs is the added complexity of async callbacks. Also pushing stuff out
> into worklets just to work around locking issues is vile.

I was asking whether it *has* to be part of synchronous CPU hotplug
operation.  IOW, do all tasks in the depleted cgroup have to be moved
to its parent before CPU hotunplug can proceed to completion or is it
okay to happen afterwards?  Making the migration part asynchronous
doesn't add much complexity.  The only thing you have to make sure is
flushing the previously scheduled one from the next CPU_UP_PREPARE.

Also note that this can't easily be solved by splitting tree
protecting inner lock from the outer lock.  We're talking about doing
full migration operations which likely require the outer one too.

> <handwave as I never can remember all the cgroup stuff/>
> 
> Can't we play games by pinning both cgroups with a reference and playing
> games with threadgroup_change / task_lock for the individual tasks being
> moved about?

I'm lost.  Can you please elaborate?

Thanks.

-- 
tejun
--
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