From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755184AbdGKCDi (ORCPT ); Mon, 10 Jul 2017 22:03:38 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:35776 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755155AbdGKCDg (ORCPT ); Mon, 10 Jul 2017 22:03:36 -0400 MIME-Version: 1.0 In-Reply-To: References: <2256f9b5-1277-c4b1-1472-61a10cd1db9a@linux.intel.com> <20170628101248.GB5981@leverpostej> <20170628105600.GC5981@leverpostej> <20170628174900.GG8252@leverpostej> <20170704090313.xyb5lntyy55ga7dm@hirez.programming.kicks-ass.net> <20170704093345.GB19649@leverpostej> <20170704102159.GB20062@leverpostej> From: Kyle Huey Date: Mon, 10 Jul 2017 19:03:35 -0700 Message-ID: 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: Mark Rutland , Ingo Molnar , gregkh@linuxfoundation.org, Peter Zijlstra Cc: Vince Weaver , "Jin, Yao" , 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Thanks, - Kyle