From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934447AbdERRVJ convert rfc822-to-8bit (ORCPT ); Thu, 18 May 2017 13:21:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59178 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933321AbdERRVF (ORCPT ); Thu, 18 May 2017 13:21:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BDCA07247C Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BDCA07247C Subject: Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics To: Tejun Heo References: <1494855256-12558-1-git-send-email-longman@redhat.com> <1494855256-12558-12-git-send-email-longman@redhat.com> <20170517214718.GH942@htj.duckdns.org> Cc: Li Zefan , Johannes Weiner , Peter Zijlstra , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, kernel-team@fb.com, pjt@google.com, luto@amacapital.net, efault@gmx.de From: Waiman Long Organization: Red Hat Message-ID: <5fd96236-532a-964f-f130-c93272edbc8e@redhat.com> Date: Thu, 18 May 2017 13:21:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170517214718.GH942@htj.duckdns.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 18 May 2017 17:21:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/17/2017 05:47 PM, Tejun Heo wrote: > Hello, Waiman. > > On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote: >> The current thread mode semantics aren't sufficient to fully support >> threaded controllers like cpu. The main problem is that when thread >> mode is enabled at root (mainly for performance reason), all the >> non-threaded controllers cannot be supported at all. >> >> To alleviate this problem, the roles of thread root and threaded >> cgroups are now further separated. Now thread mode can only be enabled >> on a non-root leaf cgroup whose parent will then become the thread >> root. All the descendants of a threaded cgroup will still need to be >> threaded. All the non-threaded resource will be accounted for in the >> thread root. Unlike the previous thread mode, however, a thread root >> can have non-threaded children where system resources like memory >> can be further split down the hierarchy. >> >> Now we could have something like >> >> R -- A -- B >> \ >> T1 -- T2 >> >> where R is the thread root, A and B are non-threaded cgroups, T1 and >> T2 are threaded cgroups. The cgroups R, T1, T2 form a threaded subtree >> where all the non-threaded resources are accounted for in R. The no >> internal process constraint does not apply in the threaded subtree. >> Non-threaded controllers need to properly handle the competition >> between internal processes and child cgroups at the thread root. >> >> This model will be flexible enough to support the need of the threaded >> controllers. > I do like the approach and it does address the issue with requiring at > least one level of nesting for the thread mode to be used with other > controllers. I need to think a bit more about it and mull over what > Peterz was suggesting in the old thread. I'll get back to you soon > but I'd really prefer this and the earlier related patches to be in > its own patchset so that we aren't dealing with different things at > the same time. > > Thanks. > I have studied the email exchanges with your original thread mode patchset. This patchset is aimed to hopefully address all the concerns that Peterz has. This enhanced thread mode should address a big part of the concern. However, I am not sure if this patch, by itself, is enough to address all his concerns. That is why I also include 2 other major changes in the next 2 patches. My goal is to move forward to allow all controllers to be enabled for v2 eventually. We are not there yet, but I hope this patchset can move thing forward meaningfully. Regards, Longman