From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39973C46466 for ; Tue, 20 Nov 2018 20:12:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 64DFA223C8 for ; Tue, 20 Nov 2018 20:11:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64DFA223C8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727610AbeKUGmj (ORCPT ); Wed, 21 Nov 2018 01:42:39 -0500 Received: from mga03.intel.com ([134.134.136.65]:49472 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725887AbeKUGmi (ORCPT ); Wed, 21 Nov 2018 01:42:38 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2018 12:11:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,258,1539673200"; d="scan'208";a="90847379" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by orsmga007.jf.intel.com with ESMTP; 20 Nov 2018 12:11:44 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id E754B3018C4; Tue, 20 Nov 2018 12:11:44 -0800 (PST) Date: Tue, 20 Nov 2018 12:11:44 -0800 From: Andi Kleen To: Kyle Huey Cc: Kan Liang , "Peter Zijlstra (Intel)" , Ingo Molnar , Robert O'Callahan , Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Linus Torvalds , Stephane Eranian , Thomas Gleixner , Vince Weaver , acme@kernel.org, open list Subject: Re: [REGRESSION] x86, perf: counter freezing breaks rr Message-ID: <20181120201144.GD13936@tassilo.jf.intel.com> References: <20181120194129.GC13936@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > Given that we're already at rc3, and that this renders rr unusable, > > > we'd ask that counter freezing be disabled for the 4.20 release. > > > > The boot option should be good enough for the release? > > I'm not entirely sure what you mean here. We want you to flip the > default boot option so this feature is off for this release. i.e. rr > should work by default on 4.20 and people should have to opt into the > inaccurate behavior if they want faster PMI servicing. I don't think it's inaccurate, it's just different than what you are used to. For profiling including the kernel it's actually far more accurate because the count is stopped much earlier near the sampling point. Otherwise there is a considerable over count into the PMI handler. In your case you limit the count to ring 3 so it's always cut off at the transition point into the kernel, while with freezing it's at the overflow point. -Andi