Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751267AbbHTEBH (ORCPT ); Thu, 20 Aug 2015 00:01:07 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:35700 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751032AbbHTEBD (ORCPT ); Thu, 20 Aug 2015 00:01:03 -0400 Message-ID: <1440043259.3515.84.camel@gmail.com> Subject: Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy From: Mike Galbraith To: Tejun Heo Cc: Paul Turner , Peter Zijlstra , Ingo Molnar , Johannes Weiner , lizefan@huawei.com, cgroups , LKML , kernel-team , Linus Torvalds , Andrew Morton Date: Thu, 20 Aug 2015 06:00:59 +0200 In-Reply-To: <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> <20150819164113.GB20716@mtj.duckdns.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1675 Lines: 34 On Wed, 2015-08-19 at 09:41 -0700, Tejun Heo wrote: > 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. If create/attach/detach/destroy aren't hot paths, what is? Those are fork/exec/exit cgroup analogs. If you have thousands upon thousands of potentially active cgroups (aka customers), you wouldn't want to keep them all around just in case when you can launch cgroup tasks the same way we launch any other task. You wouldn't contemplate slowing down fork/exec/exit, but create/attach/detach/destroy are one and the same.. they need to be just as fast/light as they can be, as they are part and parcel of the higher level process. That's why my hack ended up in a large enterprise outfit's product, it was _needed_ to fix up cgroups performance suckage. That suckage was fixed up properly quite a bit later. Anyway, if what they or anybody like them can currently do with their job launcher/manager gizmos is negatively impacted, they can gripe for themselves. All I'm saying is that there are definitely users out there to whom create/attach/detach/destroy are highly important. -Mike -- 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/