Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752289AbcJJM3x (ORCPT ); Mon, 10 Oct 2016 08:29:53 -0400 Received: from mail-lf0-f54.google.com ([209.85.215.54]:34908 "EHLO mail-lf0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667AbcJJM3w (ORCPT ); Mon, 10 Oct 2016 08:29:52 -0400 MIME-Version: 1.0 In-Reply-To: <20161010100107.GZ16071@codeblueprint.co.uk> References: <20160923115808.2330-1-matt@codeblueprint.co.uk> <20160928101422.GR5016@twins.programming.kicks-ass.net> <20160928193731.GD16071@codeblueprint.co.uk> <20161010100107.GZ16071@codeblueprint.co.uk> From: Vincent Guittot Date: Mon, 10 Oct 2016 14:29:28 +0200 Message-ID: Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue To: Matt Fleming Cc: Wanpeng Li , Peter Zijlstra , Ingo Molnar , "linux-kernel@vger.kernel.org" , Mike Galbraith , Yuyang Du , Dietmar Eggemann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1952 Lines: 44 On 10 October 2016 at 12:01, Matt Fleming wrote: > On Sun, 09 Oct, at 11:39:27AM, Wanpeng Li wrote: >> >> The difference between this patch and Peterz's is your patch have a >> delta since activate_task()->enqueue_task() does do update_rq_clock(), >> so why don't have the delta will cause low cpu machines (4 or 8) to >> regress against your another reply in this thread? > > Both my patch and Peter's patch cause issues with low cpu machines. In > <20161004201105.GP16071@codeblueprint.co.uk> I said, > > "This patch causes some low cpu machines (4 or 8) to regress. It turns > out they regress with my patch too." > > Have I misunderstood your question? > > I ran out of time to investigate this last week, though I did try all > proposed patches, including Vincent's, and none of them produced wins > across the board. I have tried to reprocude your issue on my target an hikey board (ARM based octo cores) but i failed to see a regression with commit 7dc603c9028e. Neverthless, i can see tasks not been well spread during fork as you mentioned. So I have studied a bit more the spreading issue during fork last week and i have a new version of my proposed patch that i'm going to send soon. With this patch, i can see a good spread of tasks during the fork sequence and some kind of perf improvement even if it's bit difficult as the variance is quite important with hackbench test so it's mainly an improvement of repeatability of the result > > I should get a bit further this week. > > Vincent, Dietmar, did you guys ever get around to submitting your PELT > tracepoint patches? Getting some introspection into the scheduler's My tarcepoint are not in a shape to be submitted and would need a cleanup as some are more hacks for debugging than real trace events. Nevertheless, i can push them on a git branch if they can be useful for someone > load balancing decisions would speed up this sort of research.