From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC][PATCH] cgroup_threadgroup_rwsem - affects scalability and OOM Date: Tue, 9 Aug 2016 10:26:03 -0400 Message-ID: <20160809142603.GE4906@mtj.duckdns.org> References: <4717ef90-ca86-4a34-c63a-94b8b4bfaaec@gmail.com> <20160809062900.GD4906@mtj.duckdns.org> <0a7ffe43-c0c6-85df-9bc2-d00fc837e284@gmail.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C0WHAb/iJJWFN8mZxJqHYBwy4KCq7JjwdgpZz9mE4Bk=; b=uUGoSXcaxVFABkzp4zLBEq3hKbCbuQmkASykxDzW/CRv21kRcg4WgU+f13QejzRsL9 4SI8j4VXBVUbUurJFyNZtYkOSt8rRyLmbmnGFAlqaMxF2DIbJlvLbxwGpZcOCZ3eZGJR MwAHc4I+HB9uNhQtwDD3/jymJQ8OP6I4z1kmg5nV9r95dagpjaEanTjMfVwxyC7RhaZ+ hW7RyoWoAlePSaHkB6/CaOgs+Unu3AISVAgZZaWGeswHkWcyzPrNcJHct3YNtfnMcRiC DpNpverstPVTPD5K7839okkCTeoh0/+LyDq+kXiPCFuakmJ/8+l6y2D5h59joI9kgBVN s4vA== Content-Disposition: inline In-Reply-To: <0a7ffe43-c0c6-85df-9bc2-d00fc837e284-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Balbir Singh Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Oleg Nesterov , Andrew Morton , "linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org" Hello, Balbir. On Tue, Aug 09, 2016 at 05:02:47PM +1000, Balbir Singh wrote: > > Hmm? Where does mem_cgroup_iter grab cgroup_mutex? cgroup_mutex nests > > outside cgroup_threadgroup_rwsem or most other mutexes for that matter > > and isn't exposed from cgroup core. > > > > I based my theory on the code > > mem_cgroup_iter -> css_next_descendant_pre which asserts > > cgroup_assert_mutex_or_rcu_locked(), > > although you are right, we hold RCU lock while calling css_* routines. That's "or". The iterator can be called either with RCU lock or cgroup_mutex. cgroup core may use it under cgroup_mutex. Everyone else uses it with rcu. Thanks. -- tejun From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f198.google.com (mail-yb0-f198.google.com [209.85.213.198]) by kanga.kvack.org (Postfix) with ESMTP id 5AA086B0253 for ; Tue, 9 Aug 2016 10:26:07 -0400 (EDT) Received: by mail-yb0-f198.google.com with SMTP id e125so11742848ybc.3 for ; Tue, 09 Aug 2016 07:26:07 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com. [2607:f8b0:4002:c05::244]) by mx.google.com with ESMTPS id x84si5562675ybx.336.2016.08.09.07.26.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2016 07:26:06 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id r9so574780ywg.2 for ; Tue, 09 Aug 2016 07:26:06 -0700 (PDT) Date: Tue, 9 Aug 2016 10:26:03 -0400 From: Tejun Heo Subject: Re: [RFC][PATCH] cgroup_threadgroup_rwsem - affects scalability and OOM Message-ID: <20160809142603.GE4906@mtj.duckdns.org> References: <4717ef90-ca86-4a34-c63a-94b8b4bfaaec@gmail.com> <20160809062900.GD4906@mtj.duckdns.org> <0a7ffe43-c0c6-85df-9bc2-d00fc837e284@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a7ffe43-c0c6-85df-9bc2-d00fc837e284@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Balbir Singh Cc: cgroups@vger.kernel.org, Oleg Nesterov , Andrew Morton , "linux-mm@kvack.org" Hello, Balbir. On Tue, Aug 09, 2016 at 05:02:47PM +1000, Balbir Singh wrote: > > Hmm? Where does mem_cgroup_iter grab cgroup_mutex? cgroup_mutex nests > > outside cgroup_threadgroup_rwsem or most other mutexes for that matter > > and isn't exposed from cgroup core. > > > > I based my theory on the code > > mem_cgroup_iter -> css_next_descendant_pre which asserts > > cgroup_assert_mutex_or_rcu_locked(), > > although you are right, we hold RCU lock while calling css_* routines. That's "or". The iterator can be called either with RCU lock or cgroup_mutex. cgroup core may use it under cgroup_mutex. Everyone else uses it with rcu. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org