Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752033Ab2BUCeQ (ORCPT ); Mon, 20 Feb 2012 21:34:16 -0500 Received: from mail-vw0-f46.google.com ([209.85.212.46]:56928 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761Ab2BUCeP convert rfc822-to-8bit (ORCPT ); Mon, 20 Feb 2012 21:34:15 -0500 Authentication-Results: mr.google.com; spf=pass (google.com: domain of pjt@google.com designates 10.52.26.176 as permitted sender) smtp.mail=pjt@google.com; dkim=pass header.i=pjt@google.com MIME-Version: 1.0 In-Reply-To: <87aa4dq1tq.fsf@abhimanyu.in.ibm.com> References: <20120202013825.20844.26081.stgit@kitami.mtv.corp.google.com> <87k43lde0r.fsf@linux.vnet.ibm.com> <87aa4dq1tq.fsf@abhimanyu.in.ibm.com> From: Paul Turner Date: Mon, 20 Feb 2012 18:33:44 -0800 Message-ID: Subject: Re: [RFC PATCH 00/14] sched: entity load-tracking re-work To: Nikunj A Dadhania Cc: linux-kernel@vger.kernel.org, Venki Pallipadi , Srivatsa Vaddagiri , Peter Zijlstra , Mike Galbraith , Kamalesh Babulal , Ben Segall , Ingo Molnar , Vaidyanathan Srinivasan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2154 Lines: 61 On Mon, Feb 20, 2012 at 1:41 AM, Nikunj A Dadhania wrote: > On Fri, 17 Feb 2012 02:48:06 -0800, Paul Turner wrote: >> >> This is almost certainly a result of me twiddling with the weight in >> calc_cfs_shares (using average instead of instantaneous weight) in >> this version -- see patch 11/14. ?While this had some nice stability >> properties it was not hot for fairness so I've since reverted it >> (snippet attached below). >> > For my understanding, what do you mean by stability here? The result is stable; meaning repeating the experiment returns the same number. > >> >> 24-core: >> Starting task group fair16...done >> Starting task group fair32...done >> Starting task group fair48...done >> Waiting for the task to run for 120 secs >> Interpreting the results. Please wait.... >> Time consumed by fair16 cgroup: ?12628615 Tasks: 96 >> Time consumed by fair32 cgroup: ?12562859 Tasks: 192 >> Time consumed by fair48 cgroup: ?12600364 Tasks: 288 >> > "Tasks:" should be 16,32,48? > Ah, I ran your script multiple times (for stability) above, it must not have been killing itself properly (notice each of those numbers is the respective tasks per run times 6). A correct first run on a 24-core looks like: Starting task group fair16...done Starting task group fair32...done Starting task group fair48...done Waiting for the task to run for 120 secs Interpreting the results. Please wait.... Time consumed by fair16 cgroup: 1332211 Tasks: 16 Time consumed by fair32 cgroup: 1227356 Tasks: 32 Time consumed by fair48 cgroup: 1217174 Tasks: 48 The small boost to the tasks=16 case is almost certainly tied to our current handling of sleeper credit and entity placement -- since there are less tasks than cores, whenever a task moves to a core it has not been previously executing on it gets a vruntime boost. Thanks, - Paul > Regards, > Nikunj > -- 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/