From: Takao Indoh <indou.takao@jp.fujitsu.com>
To: <alexander.shishkin@linux.intel.com>
Cc: <tglx@linutronix.de>, <mingo@redhat.com>, <hpa@zytor.com>,
<a.p.zijlstra@chello.nl>, <acme@kernel.org>, <vgoyal@redhat.com>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>
Subject: Re: [PATCH RFC 2/3] x86: Add Intel PT logger
Date: Wed, 26 Aug 2015 17:10:54 +0900 [thread overview]
Message-ID: <55DD748E.8000905@jp.fujitsu.com> (raw)
In-Reply-To: <876153binx.fsf@ashishki-desk.ger.corp.intel.com>
On 2015/07/29 15:08, Alexander Shishkin wrote:
> Takao Indoh <indou.takao@jp.fujitsu.com> writes:
>
>> This patch provides Intel PT logging feature. When system boots with a
>> parameter "intel_pt_log", log buffers for Intel PT are allocated and
>> logging starts, then processor flow information is written in the log
>> buffer by hardware like flight recorder. This is very helpful to
>> investigate a cause of kernel panic.
>>
>> The log buffer size is specified by the parameter
>> "intel_pt_log_buf_len=<size>". This buffer is used as circular buffer,
>> therefore old events are overwritten by new events.
>
> [skip]
>
>> +static void enable_pt(int enable)
>> +{
>> + u64 ctl;
>> +
>> + rdmsrl(MSR_IA32_RTIT_CTL, ctl);
>
> Ideally, you shouldn't need this rdmsr(), because in this code you
> should know exactly which ctl bits you need set when you enable.
>
>> +
>> + if (enable)
>> + ctl |= RTIT_CTL_TRACEEN;
>> + else
>> + ctl &= ~RTIT_CTL_TRACEEN;
>> +
>> + wrmsrl(MSR_IA32_RTIT_CTL, ctl);
>> +}
>
> But the bigger problem with this approach is that it duplicates the
> existing driver's functionality and some of the code, which just makes
> it harder to maintain amoung other things.
>
> Instead, we should be able to do use the existing perf functionality to
> enable the system-wide tracing, so that it goes through the
> 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.
Alexander,
I checked perf code to find out what kinds of information are needed as
side-band data. It seems that the following two events are used.
- sched:sched_switch
- dummy(PERF_COUNT_SW_DUMMY)
So, what I need to do is adding kernel counter for three events
(intel_pt, sched:sched_switch, dummy). My understanding is correct?
Thanks,
Takao Indoh
>
> Something like:
>
> static DEFINE_PER_CPU(struct perf_event *, perf_kdump_event);
>
> static struct perf_event_attr perf_kdump_attr;
>
> ...
>
> static int perf_kdump_init(void)
> {
> struct perf_event *event;
> int cpu;
>
> get_online_cpus();
> for_each_possible_cpu(cpu) {
> event = perf_create_kernel_counter(&perf_kdump_attr,
> cpu, NULL,
> NULL, NULL);
>
> ...
>
> ret = rb_alloc_kernel(event, perf_kdump_data_size, perf_kdump_aux_size);
>
> ...
>
> per_cpu(perf_kdump_event, cpu) = event;
> }
> put_online_cpus();
> }
>
next prev parent reply other threads:[~2015-08-26 8:11 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
2015-07-30 5:32 ` Alexander Shishkin
2015-08-26 8:10 ` Takao Indoh [this message]
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=55DD748E.8000905@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.