[U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB

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

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

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

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

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%20J...
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

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%20J...
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

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!
participants (2)
-
Heinrich Schuchardt
-
Simon Glass