Received: by 10.223.185.116 with SMTP id b49csp1025772wrg; Wed, 21 Feb 2018 10:47:09 -0800 (PST) X-Google-Smtp-Source: AH8x225tCDe34WiOmMFL37l+hXiGWfuPQ1j0ls+Ohh1YNggjHs13g7g+6nuqFe1Y4pIAClP9+guC X-Received: by 2002:a17:902:46a:: with SMTP id 97-v6mr3921478ple.96.1519238829101; Wed, 21 Feb 2018 10:47:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519238829; cv=none; d=google.com; s=arc-20160816; b=QpMVYHQ4qTccVJA21GUhG/GBiEEpvOCGKOzE1RscalTjbvxOrdfWm0oespcCnuR2N0 oNTSZxFoa1SvPD/D+3WFOEp9tUKAfUg+BY2IpyahHuLnJj0Yjhi7z3gv1RFr+u9V3rwL dcEZ3+TjbO5ZpgT/i/8OTkEOl3+IlNDCxX6INe3fmTUDYyaFrLSlaoxkxztpxjtnNa/G jl27lWr36D/G4PZ1vEtLI5HFnnfy0zXnf5/TYuK1CYsqC6hSzzy33ayzdQ70WJsQ1wvt NKm9Tbtyc+8umvFNHfQvLP/auD4cYKxWr9VG4Be7vs8vAWthqai63LlznK7uRFGYaLz+ 7iKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject:arc-authentication-results; bh=WTYxa/Zs4CVh+K82dFfgqo7sDNjWFWJ5oNqEJ5Oq/e8=; b=WQz7oCw0R/oKyX465jFSRDfrF6O6gxx2v4ZWmi8SsCWr9Crlg0vGywxt8C1zZQ3mPl OPMZd590vG7WXYqvfieUorOY52T/DrGn940hHdr/qQxrtDGips43IjpfWpwM5L3bynTa mXoJ7Kf7kWiMSLeywLl7ezxXOfS/MFv85kRDeQUOoCCnKnmDQqPSPRJDKZOTPnnBoWkt 2GN8lsYSuGwCI6lPy9LMJHW9WMtlgaEVcFEogljFe0+meN5l/jajAjZKAmePdvPjQiCu 26PTbww3U3vVqFpd2J8Z4OK95ZRtYi2q6QNgPN8LQ8Cya0Z9NF4nnQ0hRZiksbFogMsI aaqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4si7292443pfh.138.2018.02.21.10.46.54; Wed, 21 Feb 2018 10:47:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936825AbeBUNsk (ORCPT + 99 others); Wed, 21 Feb 2018 08:48:40 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55008 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933544AbeBUNse (ORCPT ); Wed, 21 Feb 2018 08:48:34 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0570C1435; Wed, 21 Feb 2018 05:48:34 -0800 (PST) Received: from [10.1.206.74] (e113632-lin.cambridge.arm.com [10.1.206.74]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C3EEF3F318; Wed, 21 Feb 2018 05:48:32 -0800 (PST) Subject: Re: [PATCH v5 1/3] sched: Stop nohz stats when decayed From: Valentin Schneider To: Vincent Guittot Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , Morten Rasmussen , Brendan Jackman , Dietmar Eggemann References: <1518622006-16089-1-git-send-email-vincent.guittot@linaro.org> <1518622006-16089-2-git-send-email-vincent.guittot@linaro.org> <44a7d9dc-f6f3-e003-44d6-b0c4aa7dc046@arm.com> Message-ID: Date: Wed, 21 Feb 2018 13:48:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/21/2018 01:13 PM, Valentin Schneider wrote: > On 02/16/2018 01:44 PM, Vincent Guittot wrote: >> On 16 February 2018 at 13:13, Valentin Schneider >> wrote: >>> On 02/14/2018 03:26 PM, Vincent Guittot wrote: > BTW, with the current set on Peter's sched/testing, update_nohz_stats() > is called here, which doesn't do the update if !rq->has_blocked_load > (Although that check is done without lock/barrier, so maybe we could not see > a CPU that just went idle ?) Ignore that, that's another case of me being overly paranoid after reading too much of Documentation/memory-barriers.txt