Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999Ab2BQNA6 (ORCPT ); Fri, 17 Feb 2012 08:00:58 -0500 Received: from mail-vx0-f174.google.com ([209.85.220.174]:46517 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866Ab2BQNA5 convert rfc822-to-8bit (ORCPT ); Fri, 17 Feb 2012 08:00:57 -0500 MIME-Version: 1.0 In-Reply-To: <1329407875.2293.239.camel@twins> References: <20120202013825.20844.26081.stgit@kitami.mtv.corp.google.com> <20120202013826.20844.47587.stgit@kitami.mtv.corp.google.com> <1329407875.2293.239.camel@twins> From: Paul Turner Date: Fri, 17 Feb 2012 05:00:26 -0800 Message-ID: Subject: Re: [RFC PATCH 05/14] sched: account for blocked load waking back up To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Venki Pallipadi , Srivatsa Vaddagiri , 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: 1383 Lines: 28 On Thu, Feb 16, 2012 at 7:57 AM, Peter Zijlstra wrote: > On Wed, 2012-02-01 at 17:38 -0800, Paul Turner wrote: >> + ? ? ? ? ? ? ? if (se->avg.decay_count) { >> + ? ? ? ? ? ? ? ? ? ? ? /* >> + ? ? ? ? ? ? ? ? ? ? ? ?* In a wake-up migration we have to approximate the >> + ? ? ? ? ? ? ? ? ? ? ? ?* time sleeping. >> + ? ? ? ? ? ? ? ? ? ? ? ?*/ >> + ? ? ? ? ? ? ? ? ? ? ? se->avg.last_runnable_update -= (-se->avg.decay_count) >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? << 20; >> + ? ? ? ? ? ? ? ? ? ? ? update_entity_load_avg(se, 0); >> + ? ? ? ? ? ? ? } > > That comment wants more why and how. I think I remember pjt telling me > about this last week, but those are already vague memories, I'll be sure > to be completely clueless in another week. The full reason is short enough to practically supplant the existing comment: We can't synchronize clock_task between our old-cpu and our new [don't have the locks and 32-bit says you can't have nice things], so we can use our carried decays (which we can grab atomically for exactly this reason) to approximate that. I'll update appropriately. -- 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/