From: saiprakash.ranjan@codeaurora.org (Sai Prakash Ranjan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] pstore: Add event tracing support
Date: Sat, 22 Sep 2018 22:07:00 +0530 [thread overview]
Message-ID: <e8fdef37-afcd-24b3-1005-e707b73f20b1@codeaurora.org> (raw)
In-Reply-To: <CAEXW_YRXQwKvnahv5X1F_Bu_98vMg=w1xpo8PZ+aNT02vBrwwg@mail.gmail.com>
On 9/22/2018 2:35 PM, Joel Fernandes wrote:
> On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>>
> Could you just split the pstore space into a per-cpu event buffer like
> we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
> the lock contention will be apparent. The pstore code already has
> plumbing to split the store buffer per CPU.
>
Hi Joel,
Thanks a lot for reviewing.
I just looked at per-cpu buffer for ftrace and itseems the pstore percpu
records will need to be merged into one record if we add this support
for events. Merging of ftrace logs is based on timestamp, but for events
we do not have timestamp field (for this specific reason I have added
timestamp field for IO event tracing so that atleast we can know the cpu
number in pstore output). For example, the sched event pstore output
below has no timestamp field, so how do we merge per-cpu logs?
# tail /sys/fs/pstore/event-ramoops-0
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002
Also Pstore ftrace log format is fixed i.e.,(CPU:%d ts:%llu %08lx %08lx
%pf <- %pF\n"), but different events will have different formats and
we will not be able to add timestamp field like how pstore ftrace does
using pstore_ftrace_write_timestamp() and pstore_ftrace_read_timestamp().
Sorry if I am confusing you, I can explain better I guess.
> Also I think this spinlock can be moved further down.
>
OK. Something like this would suffice?
{{{
spin_lock_irqsave(&psinfo->buf_lock, flags);
record.buf = (char *)(seq->buffer);
record.size = seq->len;
psinfo->write(&record);
spin_unlock_irqrestore(&psinfo->buf_lock, flags);
}}}
>> +
>> + trace_seq_init(&iter->seq);
>> + iter->ent = fbuffer->entry;
>> + event_call->event.funcs->trace(iter, 0, event);
>> + trace_seq_putc(&iter->seq, 0);
>
> Would it be possible to store the binary trace record in the pstore
> buffer instead of outputting text? I suspect that will both be faster
> and less space.
>
I will try this and come back.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2018-09-22 16:37 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-08 20:27 [PATCH 0/6] Tracing register accesses with pstore and dynamic debug Sai Prakash Ranjan
2018-09-08 20:27 ` [PATCH 1/6] dt-bindings: ramoops: Add event-size property Sai Prakash Ranjan
2018-09-17 5:45 ` Rob Herring
2018-09-17 17:15 ` Sai Prakash Ranjan
2018-09-08 20:27 ` [PATCH 2/6] pstore: Add event tracing support Sai Prakash Ranjan
2018-09-11 10:46 ` Sai Prakash Ranjan
2018-09-17 17:38 ` Stephen Boyd
2018-09-17 19:43 ` Sai Prakash Ranjan
2018-09-16 7:07 ` Sai Prakash Ranjan
[not found] ` <CAEXW_YSPNqVgoYWjVAMvGg_WoRV4SC2xDH1wQWTdQfBUOMQbbQ@mail.gmail.com>
2018-09-17 14:54 ` Kees Cook
2018-09-17 17:17 ` Sai Prakash Ranjan
2018-09-17 17:13 ` Sai Prakash Ranjan
2018-09-17 23:04 ` Steven Rostedt
2018-09-18 6:24 ` Sai Prakash Ranjan
2018-09-17 23:34 ` Steven Rostedt
2018-09-18 17:52 ` Sai Prakash Ranjan
2018-09-18 20:44 ` Steven Rostedt
2018-09-18 21:13 ` Sai Prakash Ranjan
2018-09-22 6:48 ` Sai Prakash Ranjan
2018-09-22 9:05 ` Joel Fernandes
2018-09-22 16:37 ` Sai Prakash Ranjan [this message]
2018-09-22 17:32 ` Sai Prakash Ranjan
2018-09-22 17:45 ` Sai Prakash Ranjan
2018-09-23 15:33 ` Sai Prakash Ranjan
2018-09-25 20:37 ` Joel Fernandes
2018-09-25 20:39 ` Joel Fernandes
2018-09-25 20:40 ` Joel Fernandes
2018-09-26 9:52 ` Sai Prakash Ranjan
2018-09-08 20:27 ` [PATCH 3/6] tracing: Add tp_pstore cmdline to have tracepoints go to pstore Sai Prakash Ranjan
2018-09-25 21:25 ` Joel Fernandes
2018-09-26 9:46 ` Sai Prakash Ranjan
2018-10-08 14:16 ` Sai Prakash Ranjan
2018-10-08 14:36 ` Steven Rostedt
2018-10-08 22:40 ` Joel Fernandes
2018-10-09 18:22 ` Sai Prakash Ranjan
2018-10-10 19:37 ` Steven Rostedt
2018-09-08 20:27 ` [PATCH 4/6] arm64/io: Add tracepoint for register accesses Sai Prakash Ranjan
2018-09-08 20:27 ` [PATCH 5/6] arm64/io: Add header for instrumentation of io operations Sai Prakash Ranjan
2018-09-17 23:39 ` Steven Rostedt
2018-09-18 7:10 ` Sai Prakash Ranjan
2018-09-18 11:47 ` Will Deacon
2018-09-18 12:43 ` Sai Prakash Ranjan
2018-09-08 20:27 ` [PATCH 6/6] dynamic_debug: Add flag for dynamic event tracing Sai Prakash Ranjan
2018-09-11 15:11 ` [PATCH 0/6] Tracing register accesses with pstore and dynamic debug Will Deacon
2018-09-11 16:11 ` Sai Prakash Ranjan
2018-10-20 5:25 ` Joel Fernandes
2018-10-20 6:32 ` Sai Prakash Ranjan
2018-10-20 16:27 ` Joel Fernandes
2018-10-21 3:46 ` Sai Prakash Ranjan
2018-10-21 4:59 ` Sai Prakash Ranjan
2018-10-21 5:09 ` Joel Fernandes
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=e8fdef37-afcd-24b3-1005-e707b73f20b1@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).