Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932101AbbFDSwT (ORCPT ); Thu, 4 Jun 2015 14:52:19 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35013 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752330AbbFDSwN (ORCPT ); Thu, 4 Jun 2015 14:52:13 -0400 Date: Fri, 5 Jun 2015 03:52:04 +0900 From: Tejun Heo To: John Stultz Cc: lkml , Li Zefan , Jonathan Corbet , cgroups@vger.kernel.org, Android Kernel Team , Rom Lemarchand , Colin Cross , Johannes Weiner Subject: Re: [RFC][PATCH 0/2] Android style loosening of cgroup attach permissions Message-ID: <20150604185204.GQ20091@mtj.duckdns.org> References: <1432179674-19154-1-git-send-email-john.stultz@linaro.org> <20150603055057.GE20091@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2322 Lines: 50 Hello, John. On Thu, Jun 04, 2015 at 10:11:17AM -0700, John Stultz wrote: > And at least in the current android-3.18 kernel, I don't see any rcu > sync modifications. But maybe I'm missing what you mean? It was from years ago so maybe it's no longer needed anymore and removed but there was a patch in the android kernel to remove synchronize_rcu() somewhere to make things go faster, which was fine for android's use case at the time but would lead to oops in other cases. Hmmm... the upstream kernel dropped synchronize_rcu() quite a while ago so maybe that's why it's no longer there. > > Given that, I'm not sure this patchset makes sense for upstream. > > Right, I'm not suggesting the patch go in "as-is". I just wanted to > show what Android is currently using, and start a discussion of what > would be a better approach for Android to use, or what the kernel > might need to be able to support Android's use case. Sure, it'd be great if android's cgroup usage converges with other use cases. The main problem I see is that for controllers with persistent state (memcg), migration is either gonna be extremely expensive or won't update existing charge state and this is a lot more of a fundamental property rather than an incidental technical detail. Each page requires tracking info and access to that tracking info must be optimized for hot path memory operations - some of them get really hot, so we can't pay much overhead there both in terms of locking and indirection, which pretty much implies that updating the association of each object is gonna be extremely expensive and likely fragile with weird corner cases where things don't quite work as expected and so on. While currently this primarily matters only to memcg, I think it's reasonable to assume that for any resource tracking regarding persistent objects similar attributes are likely to be in play and as such the general direction of cgroup development is towards mostly static organizational structure with dynamic config update happening through per-controller knobs. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/