Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752276AbbHTHwh (ORCPT ); Thu, 20 Aug 2015 03:52:37 -0400 Received: from mail-pd0-f178.google.com ([209.85.192.178]:35697 "EHLO mail-pd0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751090AbbHTHwf (ORCPT ); Thu, 20 Aug 2015 03:52:35 -0400 Date: Thu, 20 Aug 2015 00:52:32 -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: <20150820075232.GA27917@mtj.duckdns.org> References: <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> <1440043259.3515.84.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440043259.3515.84.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: 2739 Lines: 59 Hey, Mike. On Thu, Aug 20, 2015 at 06:00:59AM +0200, Mike Galbraith wrote: > 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 Things like page faults? cgroup controllers hook into subsystems and their hot path operations get affected by the method of cgroup association. Also, migration and create/destroy are completely different. create/destroy don't need much synchronization - a new task is made visible only after the initial association is set up and a dying task's association is destroyed only after the task isn't referenced by anybody. There's nothing dynamic about those compared to migration. > 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. You're conflating two completely different operations. Also, when I say migration is a relatively expensive operation, I'm comparing it to bouncing a request to another thread as opposed to bouncing the issuing thread to different cgroup request-by-request. > 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. Hmm... I bet you're talking about the removal of synchronize_rcu() in migration path, sure, that was a silly thing to have there but also that comparison is likely a couple orders of magnitude off of what the thread was originally talking about. > 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. Hmmm... I think this discussion got pretty badly derailed at this point. If I'm not mistaken, you're talking about tens or a few hundred millisecs of latency per migration which no longer exists and won't ever come back and the discussion originally was about something like migrating thread for issuing several IO requests versus bouncing that to a dedicated issuer thread in that domain. 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/