Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751496AbdGaTuc convert rfc822-to-8bit (ORCPT ); Mon, 31 Jul 2017 15:50:32 -0400 Received: from mout.gmx.net ([212.227.15.18]:53739 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbdGaTua (ORCPT ); Mon, 31 Jul 2017 15:50:30 -0400 Message-ID: <1501530579.9118.43.camel@gmx.de> Subject: Re: [PATCH 3/3] mm/sched: memdelay: memory health interface for systems and workloads From: Mike Galbraith To: Johannes Weiner , Peter Zijlstra Cc: Ingo Molnar , Andrew Morton , Rik van Riel , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Date: Mon, 31 Jul 2017 21:49:39 +0200 In-Reply-To: <20170731184142.GA30943@cmpxchg.org> References: <20170727153010.23347-1-hannes@cmpxchg.org> <20170727153010.23347-4-hannes@cmpxchg.org> <20170729091055.GA6524@worktop.programming.kicks-ass.net> <20170730152813.GA26672@cmpxchg.org> <20170731083111.tgjgkwge5dgt5m2e@hirez.programming.kicks-ass.net> <20170731184142.GA30943@cmpxchg.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:j2lv7EEfGutfIzbBFQMylrYWmQlX+UMNp7Kj6YQkEvPNg8a4M20 N4ctCJfyooc/1IMYx9st8cCgZp35kAP3WiLI3H5C2a5roGv2gDSjwdcsWqhdY2Abf5A/jhc I08lCFz1J69Q4SQ2osxahbhtpyQ762BL60HnCa4ACAajB5Bzi22ALygsBEk9t4YZP4r7NEm ZVx8C7Jm2dZ2sIqu206yw== X-UI-Out-Filterresults: notjunk:1;V01:K0:rsKcDs2hAss=:PZRcmio4s1NS1R6NuS51sA AQvOn27S9nlx7eucfbd8mNheTEj65gtjtGUFftmw0zeQ/AbaX1DdcvwzSZnwnUA07QsHIWz/F vFSUu6X17z57dXwbA0q8Q5GLwnbRjTPBA25TsVjDxH7VTeayw/JCLHA9EsAlLUcLFy72IAwHs EN0KFali4dSfzwOcOz8nuz3+k0fHepioh+UbmOFc9PUq8XS1699W6DGef8+EV3O68t44d3tja rEKHLz8WrrdNjNBOeHU3UngOjQ8YYw+4YDfbxPfbr6AAR/pTNRrD8k88k+XNYJn9m62E77g0b 8sNnoTkwx/oTiYsmjKkRzArReeMDmDgu4OIrfTxUknCgWoVYdjbf7r0ic/HsyixpLFVkmK548 OEwpDrwi10g605BBGjypBTscOMO2F6CTzxPOEwZmm8tJWPYS7BTMQHtBY1+UmSnNE/CHhAFKn CS85OzVL+HujQOti5OchSgPvde64U1GNHMgnYDMm82+em//C2juODTevbCI0R0mVHLuZQlQbF 6OwQ1sWzYpuwZKMyjUt8JF8b6kXnX2kB3jRYCgRUxvaMBmpe/yiWqXDSi64/OWJkaU7A2IO/5 DPfUa0AmgeKa9ZbtjZg501HPg7Wh1SYg+9ZiMQNbFcX4juhItV4+Gogjvh85rfAfUf1DgRT1t ogkNVRIaglooByxSzicYz5pTf6fJMLRBID5k5jSsJ5pEco/BjyEZ2AC/1ryZ56PYLCCfSrEkg rBd07HtjPwkyGFUDkZiW1vlPwHiv7lrHfXvjeNpnaDDtuHGK43+Ela0h3el14tYfIZYkHGzWe I/aQUM+p/piwKNZ4Jp0Fxnl0998NO9X7fOdctWZgXTpvMW7I5k= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 980 Lines: 21 On Mon, 2017-07-31 at 14:41 -0400, Johannes Weiner wrote: > > Adding an rq counter for tasks inside memdelay sections should be > straight-forward as well (except for maybe the migration cost of that > state between CPUs in ttwu that Mike pointed out). What I pointed out should be easily eliminated (zero use case).   > That leaves the question of how to track these numbers per cgroup at > an acceptable cost. The idea for a tree of cgroups is that walltime > impact of delays at each level is reported for all tasks at or below > that level. E.g. a leave group aggregates the state of its own tasks, > the root/system aggregates the state of all tasks in the system; hence > the propagation of the task state counters up the hierarchy. The crux of the biscuit is where exactly the investment return lies.  Gathering of these numbers ain't gonna be free, no matter how hard you try, and you're plugging into paths where every cycle added is made of userspace hide. -Mike