Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On Sat, 22 Jun 2019 at 13:10, Simon Glass wrote: > > On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt 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 > > --- > > 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 Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
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 wrote: > On 6/24/19 3:56 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt > wrote: > >> > >> On 6/22/19 9:10 PM, Simon Glass wrote: > >>> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt > 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 > --- > 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 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On 6/24/19 3:56 PM, Simon Glass wrote: Hi Heinrich, On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt wrote: On 6/22/19 9:10 PM, Simon Glass wrote: On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt 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 --- 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
Hi Heinrich, On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt wrote: > > On 6/22/19 9:10 PM, Simon Glass wrote: > > On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt > > 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 > >> --- > >> 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On 6/22/19 9:10 PM, Simon Glass wrote: On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt 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 --- 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB
On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt 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 > --- > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[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
---
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, );
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, );
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
