Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754911AbbHXVMn (ORCPT ); Mon, 24 Aug 2015 17:12:43 -0400 Received: from mail-qk0-f172.google.com ([209.85.220.172]:33634 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751989AbbHXVMl (ORCPT ); Mon, 24 Aug 2015 17:12:41 -0400 Date: Mon, 24 Aug 2015 17:12:38 -0400 From: Tejun Heo To: Paul Turner Cc: Austin S Hemmelgarn , Peter Zijlstra , Ingo Molnar , Johannes Weiner , lizefan@huawei.com, cgroups , LKML , kernel-team , Linus Torvalds , Andrew Morton Subject: Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Message-ID: <20150824211238.GI28944@mtj.duckdns.org> References: <20150818203117.GC15739@mtj.duckdns.org> <20150822182916.GE20768@mtj.duckdns.org> <55DB3C76.5010009@gmail.com> <20150824170427.GA27262@mtj.duckdns.org> <55DB77F1.5080802@gmail.com> <20150824202509.GF28944@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: 1553 Lines: 33 Hello, Paul. On Mon, Aug 24, 2015 at 02:00:54PM -0700, Paul Turner wrote: > > Hmmm... I'm trying to understand the usecases where having hierarchy > > inside a process are actually required so that we don't end up doing > > something complex unnecessarily. So far, it looks like an easy > > alternative for qemu would be teaching it to manage priorities of its > > threads given that the threads are mostly static - vcpus going up and > > down are explicit operations which can trigger priority adjustments if > > necessary, which is unlikely to begin with. > > What you're proposing is both unnecessarily complex and imprecise. > Arbitrating competition between groups of threads is exactly why we > support sub-hierarchies within cpu. Sure, and to make that behave half-way acceptable, we'll have to take on significant amount of effort and likely complexity and I'm trying to see whether the usecases are actually justifiable. I get that priority based solution will be less precise and more complex on the application side but by how much and does the added precision enough to justify the extra facilities to support that? If it is, sure, let's get to it but it'd be great if the concrete prolem cases are properly identified and understood. I'll continue on the other reply. 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/