Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755661AbdGKNHf (ORCPT ); Tue, 11 Jul 2017 09:07:35 -0400 Received: from mga06.intel.com ([134.134.136.31]:65225 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659AbdGKNHd (ORCPT ); Tue, 11 Jul 2017 09:07:33 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,346,1496127600"; d="scan'208";a="1171118028" Subject: Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region) To: Ingo Molnar , Kyle Huey Cc: Mark Rutland , gregkh@linuxfoundation.org, Peter Zijlstra , Vince Weaver , stable@vger.kernel.org, Alexander Shishkin , Arnaldo Carvalho de Melo , Jiri Olsa , Linus Torvalds , Namhyung Kim , Stephane Eranian , Thomas Gleixner , acme@kernel.org, jolsa@kernel.org, kan.liang@intel.com, Will Deacon , open list , "Robert O'Callahan" References: <20170628101248.GB5981@leverpostej> <20170628105600.GC5981@leverpostej> <20170628174900.GG8252@leverpostej> <20170704090313.xyb5lntyy55ga7dm@hirez.programming.kicks-ass.net> <20170704093345.GB19649@leverpostej> <20170704102159.GB20062@leverpostej> <20170711090358.6si4un4guz6dbxkz@gmail.com> From: "Jin, Yao" Message-ID: Date: Tue, 11 Jul 2017 21:07:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170711090358.6si4un4guz6dbxkz@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2397 Lines: 56 On 7/11/2017 5:03 PM, Ingo Molnar wrote: > * Kyle Huey wrote: > >> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan wrote: >>> On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >>>> Should any of those be moved into the "should be dropped" pile? >>> Why not be conservative and clear every sample you're not sure about? >>> >>> We'd appreciate a fix sooner rather than later here, since rr is >>> currently broken on every stable Linux kernel and our attempts to >>> implement a workaround have failed. >>> >>> (We have separate "interrupt" and "measure" counters, and I thought we >>> might work around this regression by programming the "interrupt" >>> counter to count kernel events as well as user events (interrupting >>> early is OK), but that caused our (completely separate) "measure" >>> counter to report off-by-one results (!), which seems to be a >>> different bug present on a range of older kernels.) >> This seems to have stalled out here unfortunately. >> >> Can we get a consensus (from ingo or peterz?) on Mark's question? Or, >> alternatively, can we move the patch at the top of this thread forward >> on the stable branches until we do reach an answer to that question? >> >> We've abandoned hope of working around this problem in rr and are >> currently broken for all of our users with an up-to-date kernel, so >> the situation for us is rather dire at the moment I'm afraid. > Sorry about that - I've queued up a revert for the original commit and will send > the fix to Linus later today. I've added a -stable tag as well so it can be > forwarded to Greg the moment it hits upstream. > > We should do the original fix as well, but in a version that does not skip the > sample but zeroes out the RIP and registers (or sets them all to -1LL) - and also > covers other possible places where skid-RIP is exposed, such as LBR. > > Thanks, > > Ingo Could we provide 2 options in user space when enabling the event sampling? One option is for the use case like rr debugger which only cares the PMI interrupt but doesn't care the skid. The skid samples doesn't need to be dropped. The other option is for the use case which needs the accurate sample data. For this option, the skid samples are dropped. I would suggest to let the user space make the decision to choose which option. Thanks Jin Yao