From: Takao Indoh <indou.takao@jp.fujitsu.com>
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>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>
Subject: Re: [PATCH RFC 2/3] x86: Add Intel PT logger
Date: Thu, 30 Jul 2015 10:49:04 +0900 [thread overview]
Message-ID: <55B98290.4090705@jp.fujitsu.com> (raw)
In-Reply-To: <87a8ufl493.fsf@ashishki-desk.ger.corp.intel.com>
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
>
next prev parent reply other threads:[~2015-07-30 1:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 4:51 [PATCH RFC 0/3] x86: Intel Processor Trace Logger Takao Indoh
2015-07-29 4:51 ` [PATCH RFC 1/3] x86: Add Intel PT common files Takao Indoh
2015-08-02 10:02 ` Thomas Gleixner
2015-08-03 3:14 ` Takao Indoh
2015-07-29 4:51 ` [PATCH RFC 2/3] x86: Add Intel PT logger Takao Indoh
2015-07-29 6:08 ` Alexander Shishkin
2015-07-29 8:13 ` Takao Indoh
2015-07-29 9:09 ` Alexander Shishkin
2015-07-30 1:49 ` Takao Indoh [this message]
2015-07-30 5:32 ` Alexander Shishkin
2015-08-26 8:10 ` Takao Indoh
2015-07-29 4:51 ` [PATCH RFC 3/3] x86: Stop Intel PT and save its registers when panic occurs Takao Indoh
2015-07-29 5:44 ` [PATCH RFC 0/3] x86: Intel Processor Trace Logger Alexander Shishkin
2015-07-29 5:51 ` Takao Indoh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B98290.4090705@jp.fujitsu.com \
--to=indou.takao@jp.fujitsu.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.