Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752483AbbKYL0J (ORCPT ); Wed, 25 Nov 2015 06:26:09 -0500 Received: from mail-lf0-f47.google.com ([209.85.215.47]:33359 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751675AbbKYL0H (ORCPT ); Wed, 25 Nov 2015 06:26:07 -0500 MIME-Version: 1.0 In-Reply-To: <20151125092401.GY17308@twins.programming.kicks-ass.net> References: <1448372970-8764-1-git-send-email-vincent.guittot@linaro.org> <20151125092401.GY17308@twins.programming.kicks-ass.net> From: Vincent Guittot Date: Wed, 25 Nov 2015 12:25:46 +0100 Message-ID: Subject: Re: [PATCH] sched/fair: update scale invariance of pelt To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel , Yuyang Du , Morten Rasmussen , Linaro Kernel Mailman List , Dietmar Eggemann , Paul Turner , Benjamin Segall 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: 2408 Lines: 54 On 25 November 2015 at 10:24, Peter Zijlstra wrote: > On Tue, Nov 24, 2015 at 02:49:30PM +0100, Vincent Guittot wrote: >> Instead of scaling the complete value of PELT algo, we should only scale >> the running time by the current capacity of the CPU. It seems more correct >> to only scale the running time because the non running time of a task >> (sleeping or waiting for a runqueue) is the same whatever the current freq >> and the compute capacity of the CPU. > > So I'm leaning towards liking this; however with your previous example > of 3 cpus and 7 tasks, where CPU0-1 are 'little' and of half the > capacity as the 'big' CPU2, with 2 tasks on CPU0-1 each and 3 tasks on > CPU2. > > This would result, for CPU0, in a load of 100% wait time + 100% runtime, > scaling the runtime 50% will get you a total load of 150%. > > For CPU2 we get 100% runtime and 200% wait time, no scaling, for a total > load of 300%. > > So the CPU0-1 cluster has a 300% load and the CPU2 'cluster' has a 300% > load, even though the actual load is not actually equal, CPUs0-1 > combined have the same capacity as CPU2, so it should be 4-4 tasks for > an equal balance. With the example above, we have (after that everything has reached their stable value) With the mainline: load_avg of CPU0 : 2048 and load_avg of each task should be 1024 load_avg of CPU1 : 2048 and load_avg of each task should be 1024 load_avg of CPU2 : 3072 and load_avg of each task should be 1024 With this patch which now includes the cpu invariance in the calculation of load_avg load_avg of CPU0 : 2048 and load_avg of each task should be 1024 load_avg of CPU1 : 2048 and load_avg of each task should be 1024 load_avg of CPU2 : 3072 and load_avg of each task should be 1024 The main difference will be in the time needed to reach these values. CPU2 will reach 95% of the final value in 136ms whereas the load_avg of CPU0 and CPU1 should be around 789 at that time and will reach the same value than CPU2 after additional 136ms Regards, Vincent > > > So I'm not sure the claim of comparable between CPUs stands. Still it is > an interesting idea and I will consider it more. -- 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/