From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755429AbcEQDwc (ORCPT ); Mon, 16 May 2016 23:52:32 -0400 Received: from mga04.intel.com ([192.55.52.120]:21850 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754036AbcEQDwa (ORCPT ); Mon, 16 May 2016 23:52:30 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,323,1459839600"; d="scan'208";a="956006101" Date: Tue, 17 May 2016 04:11:09 +0800 From: Yuyang Du To: Matt Fleming Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Byungchul Park , Frederic Weisbecker , Luca Abeni , "Rafael J . Wysocki" , Rik van Riel , Thomas Gleixner , Wanpeng Li , Mel Gorman , Mike Galbraith Subject: Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock() Message-ID: <20160516201109.GD8790@intel.com> References: <1463082593-27777-1-git-send-email-matt@codeblueprint.co.uk> <1463082593-27777-6-git-send-email-matt@codeblueprint.co.uk> <20160515021439.GC8790@intel.com> <20160516094638.GB6574@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160516094638.GB6574@codeblueprint.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote: > > > > > > - rq->clock_skip_update = 0; > > > + /* Clear ACT, preserve everything else */ > > > + rq->clock_update_flags ^= RQCF_ACT_SKIP; > > > > The comment says "Clear ACT", but this is really xor, and I am not sure > > this is even what you want. > > Urgh, you're right. I'm not sure what I was thinking when I wrote > that. It happens, ;) > > In addition, would it be simpler to do this? > > > > update_rq_clock() > > if (flags & RQCF_ACT_SKIP) > > flags <<= 1; /* effective skip is an update */ > > return; > > > > flags = RQCF_UPDATED; > > No because if someone calls rq_clock() immediately after __schedule(), > or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we > should trigger a warning since the clock has not actually been > updated. Well, I don't know how concurrent it can be, but aren't both update and read synchronized by rq->lock? So I don't understand the latter case, and the former should be addressed (missing its own update?).