Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1520075 > unrolled thread

[PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Kees Cook <keescook@chromium.org> - 2016-11-11 23:30 +0100
    [PATCH v3 6/8] pstore: Add ftrace timestamp counter Kees Cook <keescook@chromium.org> - 2016-11-11 23:30 +0100
    [PATCH v3 8/8] pstore: improve error report for failed setup Kees Cook <keescook@chromium.org> - 2016-11-11 23:40 +0100
    Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Joel Fernandes <joelaf@google.com> - 2016-11-15 21:00 +0100
      Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Kees Cook <keescook@chromium.org> - 2016-11-15 22:40 +0100
        Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Joel Fernandes <joelaf@google.com> - 2016-11-15 23:10 +0100
          Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Kees Cook <keescook@chromium.org> - 2016-11-15 23:20 +0100
            Re: [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops Joel Fernandes <joelaf@google.com> - 2016-11-16 07:40 +0100

#1520075 — [PATCH v3 0/8] pstore: Improve performance of ftrace backend with ramoops

Hi Joel,

I've reorganized a bunch of the logic here. Since pstore is going to need
the init_przs() logic for multiple pmsg przs, I wanted to get this in and
make sure I was happy with how it looks. I figured this would reduce our
round-trip time on reviews. :)

Can you test this series and verify that it works as you're expecting? I've
validated some basic behavior already, but don't have a good test-case for
ftrace. What commands do you actually use for testing ftrace? I'd like to
add something to my local tests.

Thanks!

-Kees

[toc] | [next] | [standalone]

#1520077 — [PATCH v3 6/8] pstore: Add ftrace timestamp counter

From: Joel Fernandes <joelaf@google.com>

In preparation for merging the per CPU buffers into one buffer when
we retrieve the pstore ftrace data, we store the timestamp as a
counter in the ftrace pstore record.  We store the CPU number as well
if !PSTORE_CPU_IN_IP, in this case we shift the counter and may lose
ordering there but we preserve the same record size. The timestamp counter
is also racy, and not doing any locking or synchronization here results
in the benefit of lower overhead. Since we don't care much here for exact
ordering of function traces across CPUs, we don't synchronize and may lose
some counter updates but I'm ok with that.

Using trace_clock() results in much lower performance so avoid using it
since we don't want accuracy in timestamp and need a rough ordering to
perform merge.

Signed-off-by: Joel Fernandes <joelaf@google.com>
[kees: updated commit message, added comments]
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/pstore/ftrace.c     |  4 +++
 fs/pstore/inode.c      |  8 ++++--
 fs/pstore/internal.h   | 34 ----------------------
 include/linux/pstore.h | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 85 insertions(+), 37 deletions(-)

diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
index d4887705bb61..31548cc09e7b 100644
--- a/fs/pstore/ftrace.c
+++ b/fs/pstore/ftrace.c
@@ -27,6 +27,9 @@
 #include <asm/barrier.h>
 #include "internal.h"
 
+/* This doesn't need to be atomic: speed is chosen over correctness here. */
+static u64 pstore_ftrace_stamp;
+
 static void notrace pstore_ftrace_call(unsigned long ip,
 				       unsigned long parent_ip,
 				       struct ftrace_ops *op,
@@ -42,6 +45,7 @@ static void notrace pstore_ftrace_call(unsigned long ip,
 
 	rec.ip = ip;
 	rec.parent_ip = parent_ip;
+	pstore_ftrace_write_timestamp(&rec, pstore_ftrace_stamp++);
 	pstore_ftrace_encode_cpu(&rec, raw_smp_processor_id());
 	psinfo->write_buf(PSTORE_TYPE_FTRACE, 0, NULL, 0, (void *)&rec,
 			  0, sizeof(rec), psinfo);
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 1781dc50762e..0d6bbcf47d52 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -107,9 +107,11 @@ static int pstore_ftrace_seq_show(struct seq_file *s, void *v)
 	struct pstore_ftrace_seq_data *data = v;
 	struct pstore_ftrace_record *rec = (void *)(ps->data + data->off);
 
-	seq_printf(s, "%d %08lx  %08lx  %pf <- %pF\n",
-		pstore_ftrace_decode_cpu(rec), rec->ip, rec->parent_ip,
-		(void *)rec->ip, (void *)rec->parent_ip);
+	seq_printf(s, "CPU:%d ts:%llu %08lx  %08lx  %pf <- %pF\n",
+		   pstore_ftrace_decode_cpu(rec),
+		   pstore_ftrace_read_timestamp(rec),
+		   rec->ip, rec->parent_ip, (void *)rec->ip,
+		   (void *)rec->parent_ip);
 
 	return 0;
 }
diff --git a/fs/pstore/internal.h b/fs/pstore/internal.h
index e38a22b31282..da416e6591c9 100644
--- a/fs/pstore/internal.h
+++ b/fs/pstore/internal.h
@@ -5,40 +5,6 @@
 #include <linux/time.h>
 #include <linux/pstore.h>
 
-#if NR_CPUS <= 2 && defined(CONFIG_ARM_THUMB)
-#define PSTORE_CPU_IN_IP 0x1
-#elif NR_CPUS <= 4 && defined(CONFIG_ARM)
-#define PSTORE_CPU_IN_IP 0x3
-#endif
-
-struct pstore_ftrace_record {
-	unsigned long ip;
-	unsigned long parent_ip;
-#ifndef PSTORE_CPU_IN_IP
-	unsigned int cpu;
-#endif
-};
-
-static inline void
-pstore_ftrace_encode_cpu(struct pstore_ftrace_record *rec, unsigned int cpu)
-{
-#ifndef PSTORE_CPU_IN_IP
-	rec->cpu = cpu;
-#else
-	rec->ip |= cpu;
-#endif
-}
-
-static inline unsigned int
-pstore_ftrace_decode_cpu(struct pstore_ftrace_record *rec)
-{
-#ifndef PSTORE_CPU_IN_IP
-	return rec->cpu;
-#else
-	return rec->ip & PSTORE_CPU_IN_IP;
-#endif
-}
-
 #ifdef CONFIG_PSTORE_FTRACE
 extern void pstore_register_ftrace(void);
 extern void pstore_unregister_ftrace(void);
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 92013cc9cc8c..0da29cae009b 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -89,4 +89,80 @@ extern int pstore_register(struct pstore_info *);
 extern void pstore_unregister(struct pstore_info *);
 extern bool pstore_cannot_block_path(enum kmsg_dump_reason reason);
 
+struct pstore_ftrace_record {
+	unsigned long ip;
+	unsigned long parent_ip;
+	u64 ts;
+};
+
+/*
+ * ftrace related stuff: Both backends and frontends need these so expose
+ * them here.
+ */
+
+#if NR_CPUS <= 2 && defined(CONFIG_ARM_THUMB)
+#define PSTORE_CPU_IN_IP 0x1
+#elif NR_CPUS <= 4 && defined(CONFIG_ARM)
+#define PSTORE_CPU_IN_IP 0x3
+#endif
+
+#define TS_CPU_SHIFT 8
+#define TS_CPU_MASK (BIT(TS_CPU_SHIFT) - 1)
+
+/*
+ * If CPU number can be stored in IP, store it there, otherwise store it in
+ * the time stamp. This means more timestamp resolution is available when
+ * the CPU can be stored in the IP.
+ */
+#ifdef PSTORE_CPU_IN_IP
+static inline void
+pstore_ftrace_encode_cpu(struct pstore_ftrace_record *rec, unsigned int cpu)
+{
+	rec->ip |= cpu;
+}
+
+static inline unsigned int
+pstore_ftrace_decode_cpu(struct pstore_ftrace_record *rec)
+{
+	return rec->ip & PSTORE_CPU_IN_IP;
+}
+
+static inline u64
+pstore_ftrace_read_timestamp(struct pstore_ftrace_record *rec)
+{
+	return rec->ts;
+}
+
+static inline void
+pstore_ftrace_write_timestamp(struct pstore_ftrace_record *rec, u64 val)
+{
+	rec->ts = val;
+}
+#else
+static inline void
+pstore_ftrace_encode_cpu(struct pstore_ftrace_record *rec, unsigned int cpu)
+{
+	rec->ts &= ~(TS_CPU_MASK);
+	rec->ts |= cpu;
+}
+
+static inline unsigned int
+pstore_ftrace_decode_cpu(struct pstore_ftrace_record *rec)
+{
+	return rec->ts & TS_CPU_MASK;
+}
+
+static inline u64
+pstore_ftrace_read_timestamp(struct pstore_ftrace_record *rec)
+{
+	return rec->ts >> TS_CPU_SHIFT;
+}
+
+static inline void
+pstore_ftrace_write_timestamp(struct pstore_ftrace_record *rec, u64 val)
+{
+	rec->ts = (rec->ts & TS_CPU_MASK) | (val << TS_CPU_SHIFT);
+}
+#endif
+
 #endif /*_LINUX_PSTORE_H*/
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1520079 — [PATCH v3 8/8] pstore: improve error report for failed setup

When setting ramoops record sizes, sometimes it's not clear which
parameters contributed to the allocation failure. This adds a per-zone
name and expands the failure reports.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 fs/pstore/ram.c | 53 ++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index f5d266157964..64fd6ead82cc 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -530,7 +530,8 @@ static void ramoops_free_przs(struct ramoops_context *cxt)
 	}
 }
 
-static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
+static int ramoops_init_przs(const char *name,
+			     struct device *dev, struct ramoops_context *cxt,
 			     struct persistent_ram_zone ***przs,
 			     phys_addr_t *paddr, size_t mem_sz,
 			     ssize_t record_size,
@@ -556,24 +557,33 @@ static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
 		if (*cnt == 0)
 			return 0;
 		record_size = mem_sz / *cnt;
-		if (record_size == 0)
+		if (record_size == 0) {
+			dev_err(dev, "%s record size == 0 (%zu / %u)\n",
+				name, mem_sz, *cnt);
 			goto fail;
+		}
 	} else {
 		*cnt = mem_sz / record_size;
-		if (*cnt == 0)
+		if (*cnt == 0) {
+			dev_err(dev, "%s record count == 0 (%zu / %zu)\n",
+				name, mem_sz, record_size);
 			goto fail;
+		}
 	}
 
 	if (*paddr + mem_sz - cxt->phys_addr > cxt->size) {
-		dev_err(dev, "no room for mem region (0x%zx@0x%llx) in (0x%lx@0x%llx)\n",
+		dev_err(dev, "no room for %s mem region (0x%zx@0x%llx) in (0x%lx@0x%llx)\n",
+			name,
 			mem_sz, (unsigned long long)*paddr,
 			cxt->size, (unsigned long long)cxt->phys_addr);
 		goto fail;
 	}
 
 	zone_sz = mem_sz / *cnt;
-	if (!zone_sz)
+	if (!zone_sz) {
+		dev_err(dev, "%s zone size == 0\n", name);
 		goto fail;
+	}
 
 	prz_ar = kcalloc(*cnt, sizeof(**przs), GFP_KERNEL);
 	if (!prz_ar)
@@ -585,8 +595,9 @@ static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
 						  cxt->memtype, flags);
 		if (IS_ERR(prz_ar[i])) {
 			err = PTR_ERR(prz_ar[i]);
-			dev_err(dev, "failed to request mem region (0x%zx@0x%llx): %d\n",
-				record_size, (unsigned long long)*paddr, err);
+			dev_err(dev, "failed to request %s mem region (0x%zx@0x%llx): %d\n",
+				name, record_size,
+				(unsigned long long)*paddr, err);
 
 			while (i > 0) {
 				i--;
@@ -606,7 +617,8 @@ static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
 	return err;
 }
 
-static int ramoops_init_prz(struct device *dev, struct ramoops_context *cxt,
+static int ramoops_init_prz(const char *name,
+			    struct device *dev, struct ramoops_context *cxt,
 			    struct persistent_ram_zone **prz,
 			    phys_addr_t *paddr, size_t sz, u32 sig)
 {
@@ -614,8 +626,8 @@ static int ramoops_init_prz(struct device *dev, struct ramoops_context *cxt,
 		return 0;
 
 	if (*paddr + sz - cxt->phys_addr > cxt->size) {
-		dev_err(dev, "no room for mem region (0x%zx@0x%llx) in (0x%lx@0x%llx)\n",
-			sz, (unsigned long long)*paddr,
+		dev_err(dev, "no room for %s mem region (0x%zx@0x%llx) in (0x%lx@0x%llx)\n",
+			name, sz, (unsigned long long)*paddr,
 			cxt->size, (unsigned long long)cxt->phys_addr);
 		return -ENOMEM;
 	}
@@ -625,8 +637,8 @@ static int ramoops_init_prz(struct device *dev, struct ramoops_context *cxt,
 	if (IS_ERR(*prz)) {
 		int err = PTR_ERR(*prz);
 
-		dev_err(dev, "failed to request mem region (0x%zx@0x%llx): %d\n",
-			sz, (unsigned long long)*paddr, err);
+		dev_err(dev, "failed to request %s mem region (0x%zx@0x%llx): %d\n",
+			name, sz, (unsigned long long)*paddr, err);
 		return err;
 	}
 
@@ -712,6 +724,7 @@ static int ramoops_probe(struct platform_device *pdev)
 	if (dev_of_node(dev) && !pdata) {
 		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
 		if (!pdata) {
+			pr_err("cannot allocate platform data buffer\n");
 			err = -ENOMEM;
 			goto fail_out;
 		}
@@ -758,12 +771,13 @@ static int ramoops_probe(struct platform_device *pdev)
 
 	dump_mem_sz = cxt->size - cxt->console_size - cxt->ftrace_size
 			- cxt->pmsg_size;
-	err = ramoops_init_przs(dev, cxt, &cxt->przs, &paddr, dump_mem_sz,
-				cxt->record_size, &cxt->max_dump_cnt, 0, 0);
+	err = ramoops_init_przs("dump", dev, cxt, &cxt->przs, &paddr,
+				dump_mem_sz, cxt->record_size,
+				&cxt->max_dump_cnt, 0, 0);
 	if (err)
 		goto fail_out;
 
-	err = ramoops_init_prz(dev, cxt, &cxt->cprz, &paddr,
+	err = ramoops_init_prz("console", dev, cxt, &cxt->cprz, &paddr,
 			       cxt->console_size, 0);
 	if (err)
 		goto fail_init_cprz;
@@ -771,15 +785,16 @@ static int ramoops_probe(struct platform_device *pdev)
 	cxt->max_ftrace_cnt = (cxt->flags & RAMOOPS_FLAG_FTRACE_PER_CPU)
 				? nr_cpu_ids
 				: 1;
-	err = ramoops_init_przs(dev, cxt, &cxt->fprzs, &paddr, cxt->ftrace_size,
-				-1, &cxt->max_ftrace_cnt,
-				LINUX_VERSION_CODE,
+	err = ramoops_init_przs("ftrace", dev, cxt, &cxt->fprzs, &paddr,
+				cxt->ftrace_size, -1,
+				&cxt->max_ftrace_cnt, LINUX_VERSION_CODE,
 				(cxt->flags & RAMOOPS_FLAG_FTRACE_PER_CPU)
 					? PRZ_FLAG_NO_LOCK : 0);
 	if (err)
 		goto fail_init_fprz;
 
-	err = ramoops_init_prz(dev, cxt, &cxt->mprz, &paddr, cxt->pmsg_size, 0);
+	err = ramoops_init_prz("pmsg", dev, cxt, &cxt->mprz, &paddr,
+				cxt->pmsg_size, 0);
 	if (err)
 		goto fail_init_mprz;
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1523041

Hi Kees,

On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi Joel,
>
> I've reorganized a bunch of the logic here. Since pstore is going to need
> the init_przs() logic for multiple pmsg przs, I wanted to get this in and
> make sure I was happy with how it looks. I figured this would reduce our
> round-trip time on reviews. :)
>
> Can you test this series and verify that it works as you're expecting? I've
> validated some basic behavior already, but don't have a good test-case for
> ftrace. What commands do you actually use for testing ftrace? I'd like to
> add something to my local tests.

I normally do the following:

dd if=/dev/urandom | pv | dd of=/dev/null

and in parallel, I do a:
echo 1 > /sys/kernel/debug/pstore/record_ftrace

and then check the throughput; and then reboot the system and do a
read out of /sys/fs/pstore/ ftrace file.

I will try these patches out today and thanks for refactoring the init
prz stuff.

Regards,
Joel

[toc] | [prev] | [next] | [standalone]

#1523075

On Tue, Nov 15, 2016 at 11:55 AM, Joel Fernandes <joelaf@google.com> wrote:
> Hi Kees,
>
> On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook <keescook@chromium.org> wrote:
>> Hi Joel,
>>
>> I've reorganized a bunch of the logic here. Since pstore is going to need
>> the init_przs() logic for multiple pmsg przs, I wanted to get this in and
>> make sure I was happy with how it looks. I figured this would reduce our
>> round-trip time on reviews. :)
>>
>> Can you test this series and verify that it works as you're expecting? I've
>> validated some basic behavior already, but don't have a good test-case for
>> ftrace. What commands do you actually use for testing ftrace? I'd like to
>> add something to my local tests.
>
> I normally do the following:
>
> dd if=/dev/urandom | pv | dd of=/dev/null
>
> and in parallel, I do a:
> echo 1 > /sys/kernel/debug/pstore/record_ftrace
>
> and then check the throughput; and then reboot the system and do a
> read out of /sys/fs/pstore/ ftrace file.

Cool. Does something normally parse these? Lots of kernel addresses is
all I see. ;)

> I will try these patches out today and thanks for refactoring the init
> prz stuff.

Sure thing! It should make the multi-pmsg change easier too.

-Kees

-- 
Kees Cook
Nexus Security

[toc] | [prev] | [next] | [standalone]

#1523087

Hi Kees,

On Tue, Nov 15, 2016 at 1:36 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Nov 15, 2016 at 11:55 AM, Joel Fernandes <joelaf@google.com> wrote:
>> Hi Kees,
>>
>> On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook <keescook@chromium.org> wrote:
>>> Hi Joel,
>>>
>>> I've reorganized a bunch of the logic here. Since pstore is going to need
>>> the init_przs() logic for multiple pmsg przs, I wanted to get this in and
>>> make sure I was happy with how it looks. I figured this would reduce our
>>> round-trip time on reviews. :)
>>>
>>> Can you test this series and verify that it works as you're expecting? I've
>>> validated some basic behavior already, but don't have a good test-case for
>>> ftrace. What commands do you actually use for testing ftrace? I'd like to
>>> add something to my local tests.
>>
>> I normally do the following:
>>
>> dd if=/dev/urandom | pv | dd of=/dev/null
>>
>> and in parallel, I do a:
>> echo 1 > /sys/kernel/debug/pstore/record_ftrace
>>
>> and then check the throughput; and then reboot the system and do a
>> read out of /sys/fs/pstore/ ftrace file.
>
> Cool. Does something normally parse these? Lots of kernel addresses is
> all I see. ;)
>

It should print symbol names if KALLSYMS is working properly as it
uses %pf (in pstore_ftrace_seq_show function).

Thanks,

Joel

[toc] | [prev] | [next] | [standalone]

#1523090

On Tue, Nov 15, 2016 at 2:06 PM, Joel Fernandes <joelaf@google.com> wrote:
> Hi Kees,
>
> On Tue, Nov 15, 2016 at 1:36 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, Nov 15, 2016 at 11:55 AM, Joel Fernandes <joelaf@google.com> wrote:
>>> Hi Kees,
>>>
>>> On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> Hi Joel,
>>>>
>>>> I've reorganized a bunch of the logic here. Since pstore is going to need
>>>> the init_przs() logic for multiple pmsg przs, I wanted to get this in and
>>>> make sure I was happy with how it looks. I figured this would reduce our
>>>> round-trip time on reviews. :)
>>>>
>>>> Can you test this series and verify that it works as you're expecting? I've
>>>> validated some basic behavior already, but don't have a good test-case for
>>>> ftrace. What commands do you actually use for testing ftrace? I'd like to
>>>> add something to my local tests.
>>>
>>> I normally do the following:
>>>
>>> dd if=/dev/urandom | pv | dd of=/dev/null
>>>
>>> and in parallel, I do a:
>>> echo 1 > /sys/kernel/debug/pstore/record_ftrace
>>>
>>> and then check the throughput; and then reboot the system and do a
>>> read out of /sys/fs/pstore/ ftrace file.
>>
>> Cool. Does something normally parse these? Lots of kernel addresses is
>> all I see. ;)
>>
>
> It should print symbol names if KALLSYMS is working properly as it
> uses %pf (in pstore_ftrace_seq_show function).

Hrm. No such luck for me, but it's clearly using pstore correctly, so
I'm satisfied things are working along that path. :)

-Kees

-- 
Kees Cook
Nexus Security

[toc] | [prev] | [next] | [standalone]

#1523255

On Tue, Nov 15, 2016 at 2:14 PM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Nov 15, 2016 at 2:06 PM, Joel Fernandes <joelaf@google.com> wrote:
>> Hi Kees,
>>
>> On Tue, Nov 15, 2016 at 1:36 PM, Kees Cook <keescook@chromium.org> wrote:
>>> On Tue, Nov 15, 2016 at 11:55 AM, Joel Fernandes <joelaf@google.com> wrote:
>>>> Hi Kees,
>>>>
>>>> On Fri, Nov 11, 2016 at 2:21 PM, Kees Cook <keescook@chromium.org> wrote:
>>>>> Hi Joel,
>>>>>
>>>>> I've reorganized a bunch of the logic here. Since pstore is going to need
>>>>> the init_przs() logic for multiple pmsg przs, I wanted to get this in and
>>>>> make sure I was happy with how it looks. I figured this would reduce our
>>>>> round-trip time on reviews. :)
>>>>>
>>>>> Can you test this series and verify that it works as you're expecting? I've
>>>>> validated some basic behavior already, but don't have a good test-case for
>>>>> ftrace. What commands do you actually use for testing ftrace? I'd like to
>>>>> add something to my local tests.
>>>>
>>>> I normally do the following:
>>>>
>>>> dd if=/dev/urandom | pv | dd of=/dev/null
>>>>
>>>> and in parallel, I do a:
>>>> echo 1 > /sys/kernel/debug/pstore/record_ftrace
>>>>
>>>> and then check the throughput; and then reboot the system and do a
>>>> read out of /sys/fs/pstore/ ftrace file.
>>>
>>> Cool. Does something normally parse these? Lots of kernel addresses is
>>> all I see. ;)
>>>
>>
>> It should print symbol names if KALLSYMS is working properly as it
>> uses %pf (in pstore_ftrace_seq_show function).
>
> Hrm. No such luck for me, but it's clearly using pstore correctly, so
> I'm satisfied things are working along that path. :)

Tested your for-next/pstore branch and ftrace on pstore works fine.

Thanks!

Joel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web