Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933403Ab1D1Swd (ORCPT ); Thu, 28 Apr 2011 14:52:33 -0400 Received: from smtp-out.google.com ([216.239.44.51]:40500 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933239Ab1D1Swb convert rfc822-to-8bit (ORCPT ); Thu, 28 Apr 2011 14:52:31 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=MSJwrXIpCSXqKYvsXoLU8HFNl4Xtm3DDwntpOKw2QnFgG4KWtb1KJHZcGSsEHCQ/XQ OuO+ayCScp1TNJTnqcJw== MIME-Version: 1.0 In-Reply-To: References: <1303332697-16426-1-git-send-email-ncrao@google.com> <20110428121244.GA26851@linux.vnet.ibm.com> From: Paul Turner Date: Thu, 28 Apr 2011 11:51:59 -0700 Message-ID: Subject: Re: [RFC][PATCH 00/18] Increase resolution of load weights To: Nikhil Rao Cc: vatsa@linux.vnet.ibm.com, "Nikunj A. Dadhania" , Ingo Molnar , Peter Zijlstra , Mike Galbraith , "linux-kernel@vger.kernel.org" , Bharata B Rao 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: 2251 Lines: 48 On Thu, Apr 28, 2011 at 11:33 AM, Nikhil Rao wrote: > On Thu, Apr 28, 2011 at 5:12 AM, Srivatsa Vaddagiri > wrote: >> On Thu, Apr 28, 2011 at 05:18:27PM +0530, Nikunj A. Dadhania wrote: >>> --- kernel/sched.c.orig ? ? ? 2011-04-28 16:34:24.000000000 +0530 >>> +++ kernel/sched.c ? ?2011-04-28 16:36:29.000000000 +0530 >>> @@ -1336,7 +1336,7 @@ calc_delta_mine(unsigned long delta_exec >>> ? ? ? ? ? ? ? ? ? ? ? lw->inv_weight = 1 + (WMULT_CONST - w/2) / (w + 1); >>> ? ? ? } >>> >>> - ? ? tmp = (u64)delta_exec * weight; >>> + ? ? tmp = (u64)delta_exec * (weight >> SCHED_LOAD_RESOLUTION); >> >> Should we be fixing inv_weight rather to account for SCHED_LOAD_RESOLUTION here? >> > > Yes, I have been looking into fixing inv_weight and calc_delta_mine() > calculations based on the assumption that we have u64 weights. IMO the > function is complicated because the return value needs to be > calculated to fit into unsigned long. I would like to update users of > calc_delta_mine() to use u64 instead of unsigned longs and I think > this can be easily done (quick inspection of the code shows two call > sites that need to be updated - update_curr() and wakeup_gran()). > Without the restriction to fit into unsigned long, I think we can make > calc_delta_mine() and the inv_weight calculations simpler. > I don't think you have much room to maneuver here, the calculations in c_d_m() are already u64 based, even on 32bit. Changing the external load factors to 64 bit doesn't change this. We lose fairness in cdm beyond 32 bits, at the old LOAD_SCALE=10 you've got 22 bits with which you can maintain fairness. This gives total accuracy in total curr on any delta <= ~4ms (for a NICE_0 task). If you bump this up (and don't downshift before computing the inverse as you are) then you start introducing rounding errors beyond ~4us. This would also be further exacerbated in sched_period() since that's using the total cfs_rq weight. > -Thanks, > Nikhil > -- 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/