Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752826AbbHSQlS (ORCPT ); Wed, 19 Aug 2015 12:41:18 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:33531 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751804AbbHSQlQ (ORCPT ); Wed, 19 Aug 2015 12:41:16 -0400 Date: Wed, 19 Aug 2015 09:41:13 -0700 From: Tejun Heo To: Mike Galbraith Cc: Paul Turner , 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: <20150819164113.GB20716@mtj.duckdns.org> References: <1438641689-14655-1-git-send-email-tj@kernel.org> <1438641689-14655-4-git-send-email-tj@kernel.org> <20150804090711.GL25159@twins.programming.kicks-ass.net> <20150804151017.GD17598@mtj.duckdns.org> <20150805091036.GT25159@twins.programming.kicks-ass.net> <20150805143132.GK17598@mtj.duckdns.org> <20150818203117.GC15739@mtj.duckdns.org> <1439954620.3479.30.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1439954620.3479.30.camel@gmail.com> 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: 1533 Lines: 33 Hello, Mike. On Wed, Aug 19, 2015 at 05:23:40AM +0200, Mike Galbraith wrote: > Hm. I know of a big data outfit to which attach/detach performance was > important enough for them to have plucked an old experimental overhead > reduction hack (mine) off lkml, and shipped it. It must have mattered a > LOT for them (not suicidal crash test dummies) to have done that. There haven't been any guidelines on cgroup usage. Of course people have been developing in all directions. It's a natural learning process and there are use cases which can be served by migrating processes back and forth. Nobody is trying to prevent that; however, if one examines how resources and their associations need to be tracked for accounting and control, it's evident that there are inherent trade-offs between migration and the stuff which happens while not migrating and it's clear which side is more important. Most problems can be solved in different ways and I'm doubtful that e.g. bouncing jobs to worker threads would be more expensive than migrating the worker back and forth in a lot of cases. If migrating threads around floats somebody's boat, that's fine but that has never been and can't be the focus of design and optimization, not at the cost of the actual hot paths. 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/