Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751449AbbB1KSf (ORCPT <rfc822;w@1wt.eu>);
	Sat, 28 Feb 2015 05:18:35 -0500
Received: from bombadil.infradead.org ([198.137.202.9]:48186 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750814AbbB1KSc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 28 Feb 2015 05:18:32 -0500
Date: Sat, 28 Feb 2015 11:18:24 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: kan.liang@intel.com, linux-kernel@vger.kernel.org, mingo@redhat.com,
        acme@kernel.org
Subject: Re: [RFC PATCH 1/1] proc: introduce /proc/<pid>/lbr_stack
Message-ID: <20150228101824.GW5029@twins.programming.kicks-ass.net>
References: <1424663021-82663-1-git-send-email-kan.liang@intel.com>
 <20150223164957.GB5029@twins.programming.kicks-ass.net>
 <20150223174448.GE27767@tassilo.jf.intel.com>
 <20150227075829.GC21418@twins.programming.kicks-ass.net>
 <20150227175434.GI27767@tassilo.jf.intel.com>
 <20150227220545.GT5029@twins.programming.kicks-ass.net>
 <20150227235702.GJ27767@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150227235702.GJ27767@tassilo.jf.intel.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1287
Lines: 28

On Fri, Feb 27, 2015 at 03:57:02PM -0800, Andi Kleen wrote:
> On Fri, Feb 27, 2015 at 11:05:45PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 27, 2015 at 09:54:34AM -0800, Andi Kleen wrote:
> > > > > perf record doesn't show where you're currently blocked.
> > > > 
> > > > Of course it does; look at perf inject -s.
> > > 
> > > Trace points don't support the LBR stack.
> > 
> > Yes, indeed. But would it not make much more sense to squirrel the LBR
> > state into sched:sched_switch and teach that inject -s thing to dtrt,
> > than to make a proc file that's available on all archs but will only
> > work on 1-2 x86 uarchs and only if you're also running the right magic
> > perf record at the same time?
> 
> Yes. It would be nice to capture the whole PMU state in trace points.
> There are use models for this where it can work better than
> sampling.
> 
> But that would be a lot bigger project than this simple file,
> which is already quite useful with minimal effort.

Its also the most horrible hack of an interface ever, so no go.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/