Subject: Re: [PATCH RFC 2/3] x86: Add Intel PT logger
To: <alexander.shishkin@linux.intel.com>, <tglx@linutronix.de>,
        <mingo@redhat.com>, <hpa@zytor.com>, <a.p.zijlstra@chello.nl>,
        <acme@kernel.org>, <vgoyal@redhat.com>
References: <1438145496-5932-1-git-send-email-indou.takao@jp.fujitsu.com>
 <1438145496-5932-3-git-send-email-indou.takao@jp.fujitsu.com>
 <876153binx.fsf@ashishki-desk.ger.corp.intel.com>
 <55B88B20.4020707@jp.fujitsu.com>
 <87a8ufl493.fsf@ashishki-desk.ger.corp.intel.com>
From: Takao Indoh <indou.takao@jp.fujitsu.com>
CC: <linux-kernel@vger.kernel.org>, <x86@kernel.org>
Message-ID: <55B98290.4090705@jp.fujitsu.com>
Date: Thu, 30 Jul 2015 10:49:04 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <87a8ufl493.fsf@ashishki-desk.ger.corp.intel.com>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2045
Lines: 53

On 2015/07/29 18:09, Alexander Shishkin wrote:
> Takao Indoh <indou.takao@jp.fujitsu.com> writes:
> 
>> On 2015/07/29 15:08, Alexander Shishkin wrote:
>>> Instead, we should be able to do use the existing perf functionality to
>>> enable the system-wide tracing, so that it goes through the
>>
>> "existing driver" means PMU driver (perf_event_intel_pt.c)?
> 
> Yes.
> 
>> The feature of these patches is a sort of flight recorder. Once it
>> starts, never stop, not export anything to user, it just captures data
>> with minimum overhead in preparation for kernel panic. This usage is
>> different from perf and therefore I'm not sure whether this feature can
>> be implemented using perf infrastructure.
> 
> Why not? There is an established infrastructure for in-kernel perf
> events already, take a look at the nmi watchdog, for example.

Ok, I'm reading the code around perf_event_create_kernel_counter. It
seems to work for my purpose, I'll try to update my patch with this.

Thanks,
Takao Indoh

> 
>>> driver. Another thing to remember is that you'd also need some of the
>>> sideband data (vm mappings, context switches) to be able to properly
>>> decode the trace, which also can come from perf. And it'd also be much
>>> less code. The only missing piece is the code that would allocate the
>>> ring buffer for such events.
>>
>> The sideband data is needed if we want to reconstruct user program flow,
>> but is it needed to reconstruct kernel panic path?
> 
> You are not really interested in the panic path as much as events
> leading up to the panic and those usually have context, which is much
> easier to reconstruct with sideband info. Some of it you can reconstruct
> by walking kernel's data structures, but that is not reliable after the
> panic.
> 
> Regards,
> --
> Alex
> 


--
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/