All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
@ 2019-06-14 19:50 Heinrich Schuchardt
  2019-06-22 19:10 ` Simon Glass
  0 siblings, 1 reply; 7+ messages in thread
From: Heinrich Schuchardt @ 2019-06-14 19:50 UTC (permalink / raw)
  To: u-boot

There is no good reason to limit the trace buffer to 2GiB on a 64bit
system. Adjust the types of the relevant parameters.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 cmd/trace.c      | 10 ++++------
 include/trace.h  |  6 +++---
 lib/trace.c      | 14 +++++++-------
 tools/proftool.c |  4 ++--
 4 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/cmd/trace.c b/cmd/trace.c
index 26bf0960d4..7d328f88be 100644
--- a/cmd/trace.c
+++ b/cmd/trace.c
@@ -30,8 +30,7 @@ static int get_args(int argc, char * const argv[], char **buff,

 static int create_func_list(int argc, char * const argv[])
 {
-	size_t buff_size, avail, buff_ptr, used;
-	unsigned int needed;
+	size_t buff_size, avail, buff_ptr, needed, used;
 	char *buff;
 	int err;

@@ -41,7 +40,7 @@ static int create_func_list(int argc, char * const argv[])
 	avail = buff_size - buff_ptr;
 	err = trace_list_functions(buff + buff_ptr, avail, &needed);
 	if (err)
-		printf("Error: truncated (%#x bytes needed)\n", needed);
+		printf("Error: truncated (%#zx bytes needed)\n", needed);
 	used = min(avail, (size_t)needed);
 	printf("Function trace dumped to %08lx, size %#zx\n",
 	       (ulong)map_to_sysmem(buff + buff_ptr), used);
@@ -54,8 +53,7 @@ static int create_func_list(int argc, char * const argv[])

 static int create_call_list(int argc, char * const argv[])
 {
-	size_t buff_size, avail, buff_ptr, used;
-	unsigned int needed;
+	size_t buff_size, avail, buff_ptr, needed, used;
 	char *buff;
 	int err;

@@ -65,7 +63,7 @@ static int create_call_list(int argc, char * const argv[])
 	avail = buff_size - buff_ptr;
 	err = trace_list_calls(buff + buff_ptr, avail, &needed);
 	if (err)
-		printf("Error: truncated (%#x bytes needed)\n", needed);
+		printf("Error: truncated (%#zx bytes needed)\n", needed);
 	used = min(avail, (size_t)needed);
 	printf("Call list dumped to %08lx, size %#zx\n",
 	       (ulong)map_to_sysmem(buff + buff_ptr), used);
diff --git a/include/trace.h b/include/trace.h
index 99f34f72bc..606dba9768 100644
--- a/include/trace.h
+++ b/include/trace.h
@@ -39,7 +39,7 @@ struct trace_output_func {
 /* A header at the start of the trace output buffer */
 struct trace_output_hdr {
 	enum trace_chunk_type type;	/* Record type */
-	uint32_t rec_count;		/* Number of records */
+	size_t rec_count;		/* Number of records */
 };

 /* Print statistics about traced function calls */
@@ -57,7 +57,7 @@ void trace_print_stats(void);
  * @param needed	Returns number of bytes used / needed
  * @return 0 if ok, -1 on error (buffer exhausted)
  */
-int trace_list_functions(void *buff, int buff_size, unsigned *needed);
+int trace_list_functions(void *buff, size_t buff_size, size_t *needed);

 /* Flags for ftrace_record */
 enum ftrace_flags {
@@ -77,7 +77,7 @@ struct trace_call {
 	uint32_t flags;		/* Flags and timestamp */
 };

-int trace_list_calls(void *buff, int buff_size, unsigned int *needed);
+int trace_list_calls(void *buff, size_t buff_size, size_t *needed);

 /**
  * Turn function tracing on and off
diff --git a/lib/trace.c b/lib/trace.c
index 04780f59d3..f2402b9359 100644
--- a/lib/trace.c
+++ b/lib/trace.c
@@ -190,12 +190,12 @@ void __attribute__((no_instrument_function)) __cyg_profile_func_exit(
  *			greater than buff_size if we ran out of space.
  * @return 0 if ok, -1 if space was exhausted
  */
-int trace_list_functions(void *buff, int buff_size, unsigned int *needed)
+int trace_list_functions(void *buff, size_t buff_size, size_t *needed)
 {
 	struct trace_output_hdr *output_hdr = NULL;
 	void *end, *ptr = buff;
-	int func;
-	int upto;
+	size_t func;
+	size_t upto;

 	end = buff ? buff + buff_size : NULL;

@@ -206,7 +206,7 @@ int trace_list_functions(void *buff, int buff_size, unsigned int *needed)

 	/* Add information about each function */
 	for (func = upto = 0; func < hdr->func_count; func++) {
-		int calls = hdr->call_accum[func];
+		size_t calls = hdr->call_accum[func];

 		if (!calls)
 			continue;
@@ -235,12 +235,12 @@ int trace_list_functions(void *buff, int buff_size, unsigned int *needed)
 	return 0;
 }

-int trace_list_calls(void *buff, int buff_size, unsigned *needed)
+int trace_list_calls(void *buff, size_t buff_size, size_t *needed)
 {
 	struct trace_output_hdr *output_hdr = NULL;
 	void *end, *ptr = buff;
-	int rec, upto;
-	int count;
+	size_t rec, upto;
+	size_t count;

 	end = buff ? buff + buff_size : NULL;

diff --git a/tools/proftool.c b/tools/proftool.c
index c1803fa78a..fecb9d6e99 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -205,12 +205,12 @@ static struct func_info *find_caller_by_offset(uint32_t offset)
 	return low >= 0 ? &func_list[low] : NULL;
 }

-static int read_calls(FILE *fin, int count)
+static int read_calls(FILE *fin, size_t count)
 {
 	struct trace_call *call_data;
 	int i;

-	notice("call count: %d\n", count);
+	notice("call count: %zu\n", count);
 	call_list = (struct trace_call *)calloc(count, sizeof(*call_data));
 	if (!call_list) {
 		error("Cannot allocate call_list\n");
--
2.20.1

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-14 19:50 [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB Heinrich Schuchardt
@ 2019-06-22 19:10 ` Simon Glass
  2019-06-22 19:37   ` Heinrich Schuchardt
  2019-06-28 13:55   ` Simon Glass
  0 siblings, 2 replies; 7+ messages in thread
From: Simon Glass @ 2019-06-22 19:10 UTC (permalink / raw)
  To: u-boot

On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> There is no good reason to limit the trace buffer to 2GiB on a 64bit
> system. Adjust the types of the relevant parameters.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>  cmd/trace.c      | 10 ++++------
>  include/trace.h  |  6 +++---
>  lib/trace.c      | 14 +++++++-------
>  tools/proftool.c |  4 ++--
>  4 files changed, 16 insertions(+), 18 deletions(-)

Wow it's going to take a very long time to transfer that much data
over your network.

Reviewed-by: Simon Glass <sjg@chromium.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-22 19:10 ` Simon Glass
@ 2019-06-22 19:37   ` Heinrich Schuchardt
  2019-06-24 13:56     ` Simon Glass
  2019-06-28 13:55   ` Simon Glass
  1 sibling, 1 reply; 7+ messages in thread
From: Heinrich Schuchardt @ 2019-06-22 19:37 UTC (permalink / raw)
  To: u-boot

On 6/22/19 9:10 PM, Simon Glass wrote:
> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> There is no good reason to limit the trace buffer to 2GiB on a 64bit
>> system. Adjust the types of the relevant parameters.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>>   cmd/trace.c      | 10 ++++------
>>   include/trace.h  |  6 +++---
>>   lib/trace.c      | 14 +++++++-------
>>   tools/proftool.c |  4 ++--
>>   4 files changed, 16 insertions(+), 18 deletions(-)
>
> Wow it's going to take a very long time to transfer that much data
> over your network.

Thanks for reviewing.

I am writing files with the traces to the mounted file system.

I activated traces in lib/efi_loader only and found several hundred
thousand function calls just to start Shell.efi which ended up in
exceeding the trace buffer. This is why want to lift unnecessary
restrictions.

What I still need to write is a script to analyze the traces to
calculate the gross and the net time spent in each function.

Regards

Heinrich

>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-22 19:37   ` Heinrich Schuchardt
@ 2019-06-24 13:56     ` Simon Glass
  2019-06-24 17:30       ` Heinrich Schuchardt
  0 siblings, 1 reply; 7+ messages in thread
From: Simon Glass @ 2019-06-24 13:56 UTC (permalink / raw)
  To: u-boot

Hi Heinrich,

On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 6/22/19 9:10 PM, Simon Glass wrote:
> > On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> There is no good reason to limit the trace buffer to 2GiB on a 64bit
> >> system. Adjust the types of the relevant parameters.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >>   cmd/trace.c      | 10 ++++------
> >>   include/trace.h  |  6 +++---
> >>   lib/trace.c      | 14 +++++++-------
> >>   tools/proftool.c |  4 ++--
> >>   4 files changed, 16 insertions(+), 18 deletions(-)
> >
> > Wow it's going to take a very long time to transfer that much data
> > over your network.
>
> Thanks for reviewing.
>
> I am writing files with the traces to the mounted file system.
>
> I activated traces in lib/efi_loader only and found several hundred
> thousand function calls just to start Shell.efi which ended up in
> exceeding the trace buffer. This is why want to lift unnecessary
> restrictions.
>
> What I still need to write is a script to analyze the traces to
> calculate the gross and the net time spent in each function.

OK I see, sounds good. Also, I suppose you saw that you can use
pytimechart to view the data, as in README.trace


- Simon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-24 13:56     ` Simon Glass
@ 2019-06-24 17:30       ` Heinrich Schuchardt
  2019-06-24 18:40         ` Simon Glass
  0 siblings, 1 reply; 7+ messages in thread
From: Heinrich Schuchardt @ 2019-06-24 17:30 UTC (permalink / raw)
  To: u-boot

On 6/24/19 3:56 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 6/22/19 9:10 PM, Simon Glass wrote:
>>> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> There is no good reason to limit the trace buffer to 2GiB on a 64bit
>>>> system. Adjust the types of the relevant parameters.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> ---
>>>>    cmd/trace.c      | 10 ++++------
>>>>    include/trace.h  |  6 +++---
>>>>    lib/trace.c      | 14 +++++++-------
>>>>    tools/proftool.c |  4 ++--
>>>>    4 files changed, 16 insertions(+), 18 deletions(-)
>>>
>>> Wow it's going to take a very long time to transfer that much data
>>> over your network.
>>
>> Thanks for reviewing.
>>
>> I am writing files with the traces to the mounted file system.
>>
>> I activated traces in lib/efi_loader only and found several hundred
>> thousand function calls just to start Shell.efi which ended up in
>> exceeding the trace buffer. This is why want to lift unnecessary
>> restrictions.
>>
>> What I still need to write is a script to analyze the traces to
>> calculate the gross and the net time spent in each function.
>
> OK I see, sounds good. Also, I suppose you saw that you can use
> pytimechart to view the data, as in README.trace

Yes, thanks I saw it. I would like to get output like this:

https://sapinsider.wispubs.com/-/media/Alloy/Images/Assets/Articles/2018%20January/SPI-01-2018_Mensch_Fig07-large.jpg

where for each function I see:

* number of invocations
* gross time (sum of individual exit time minus entry time)
* net time (the same but without the calls invoked by the function)

Regards

Heinrich

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-24 17:30       ` Heinrich Schuchardt
@ 2019-06-24 18:40         ` Simon Glass
  0 siblings, 0 replies; 7+ messages in thread
From: Simon Glass @ 2019-06-24 18:40 UTC (permalink / raw)
  To: u-boot

Hi Heinrich,

OK...I can't remember the details but there is a tool that does that. The
format that U-Boot's proftool emits is pretty standard. I recall using it
with a tool the kernel uses to get info like you are looking for.

Regards,
Simon


On Mon, 24 Jun 2019 at 11:30, Heinrich Schuchardt <xypron.glpk@gmx.de>
wrote:

> On 6/24/19 3:56 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> >>
> >> On 6/22/19 9:10 PM, Simon Glass wrote:
> >>> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de>
> wrote:
> >>>>
> >>>> There is no good reason to limit the trace buffer to 2GiB on a 64bit
> >>>> system. Adjust the types of the relevant parameters.
> >>>>
> >>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>> ---
> >>>>    cmd/trace.c      | 10 ++++------
> >>>>    include/trace.h  |  6 +++---
> >>>>    lib/trace.c      | 14 +++++++-------
> >>>>    tools/proftool.c |  4 ++--
> >>>>    4 files changed, 16 insertions(+), 18 deletions(-)
> >>>
> >>> Wow it's going to take a very long time to transfer that much data
> >>> over your network.
> >>
> >> Thanks for reviewing.
> >>
> >> I am writing files with the traces to the mounted file system.
> >>
> >> I activated traces in lib/efi_loader only and found several hundred
> >> thousand function calls just to start Shell.efi which ended up in
> >> exceeding the trace buffer. This is why want to lift unnecessary
> >> restrictions.
> >>
> >> What I still need to write is a script to analyze the traces to
> >> calculate the gross and the net time spent in each function.
> >
> > OK I see, sounds good. Also, I suppose you saw that you can use
> > pytimechart to view the data, as in README.trace
>
> Yes, thanks I saw it. I would like to get output like this:
>
>
> https://sapinsider.wispubs.com/-/media/Alloy/Images/Assets/Articles/2018%20January/SPI-01-2018_Mensch_Fig07-large.jpg
>
> where for each function I see:
>
> * number of invocations
> * gross time (sum of individual exit time minus entry time)
> * net time (the same but without the calls invoked by the function)
>
> Regards
>
> Heinrich
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
  2019-06-22 19:10 ` Simon Glass
  2019-06-22 19:37   ` Heinrich Schuchardt
@ 2019-06-28 13:55   ` Simon Glass
  1 sibling, 0 replies; 7+ messages in thread
From: Simon Glass @ 2019-06-28 13:55 UTC (permalink / raw)
  To: u-boot

On Sat, 22 Jun 2019 at 13:10, Simon Glass <sjg@chromium.org> wrote:
>
> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >
> > There is no good reason to limit the trace buffer to 2GiB on a 64bit
> > system. Adjust the types of the relevant parameters.
> >
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> >  cmd/trace.c      | 10 ++++------
> >  include/trace.h  |  6 +++---
> >  lib/trace.c      | 14 +++++++-------
> >  tools/proftool.c |  4 ++--
> >  4 files changed, 16 insertions(+), 18 deletions(-)
>
> Wow it's going to take a very long time to transfer that much data
> over your network.
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-dm/next, thanks!

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-06-28 13:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-14 19:50 [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB Heinrich Schuchardt
2019-06-22 19:10 ` Simon Glass
2019-06-22 19:37   ` Heinrich Schuchardt
2019-06-24 13:56     ` Simon Glass
2019-06-24 17:30       ` Heinrich Schuchardt
2019-06-24 18:40         ` Simon Glass
2019-06-28 13:55   ` Simon Glass

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.