* [PATCH 1/3] Support new mallinfo2 function.
@ 2020-09-01 12:31 Martin Liška
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Martin Liška @ 2020-09-01 12:31 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
Hey.
I've just applied to patches to glibc introducing a new mallinfo2 function.
Limitation of the current function mallinfo is usage of int type which overflows
for allocation > 2GB.
The patch adds configure detection and usage of the new one. And it prints heap usage
in MiB.
Ready to be installed after tests?
Thanks,
Martin
[-- Attachment #2: 0001-Support-new-mallinfo2-function.patch --]
[-- Type: text/x-patch, Size: 4699 bytes --]
From 031ae63018a32c9ac10fab58f4a6c8b5a9166060 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Tue, 1 Sep 2020 14:14:45 +0200
Subject: [PATCH 1/3] Support new mallinfo2 function.
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Likewise.
* configure.ac: Detect for mallinfo2.
* ggc-common.c (defined): Use it and display info in MiB.
* system.h: Handle also HAVE_MALLINFO2.
---
gcc/config.in | 16 ++++++++++++++--
gcc/configure | 4 ++--
gcc/configure.ac | 4 ++--
gcc/ggc-common.c | 12 +++++++++---
gcc/system.h | 2 +-
5 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/gcc/config.in b/gcc/config.in
index 478e74fac02..1832c112ed9 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -983,13 +983,19 @@
#endif
-/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to
- 0. */
+/* Define to 1 if we found a declaration for 'mallinfo */
#ifndef USED_FOR_TARGET
#undef HAVE_DECL_MALLINFO
#endif
+/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to
+ 0. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_DECL_MALLINFO2
+#endif
+
+
/* Define to 1 if we found a declaration for 'malloc', otherwise define to 0.
*/
#ifndef USED_FOR_TARGET
@@ -1665,6 +1671,12 @@
#endif
+/* Define to 1 if you have the `mallinfo2' function. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_MALLINFO2
+#endif
+
+
/* Define to 1 if you have the <malloc.h> header file. */
#ifndef USED_FOR_TARGET
#undef HAVE_MALLOC_H
diff --git a/gcc/configure b/gcc/configure
index 0f7a8dbe0f9..b8b9bd3505b 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -10120,7 +10120,7 @@ fi
for ac_func in times clock kill getrlimit setrlimit atoq \
popen sysconf strsignal getrusage nl_langinfo \
gettimeofday mbstowcs wcswidth mmap setlocale \
- clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo
+ clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2
do :
as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var"
@@ -11549,7 +11549,7 @@ fi
done
-for ac_func in mallinfo
+for ac_func in mallinfo, mallinfo2
do
ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp`
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0f11238c19f..18640fdb8a5 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl
AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \
popen sysconf strsignal getrusage nl_langinfo \
gettimeofday mbstowcs wcswidth mmap setlocale \
- gcc_UNLOCKED_FUNCS madvise mallinfo)
+ gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2)
if test x$ac_cv_func_mbstowcs = xyes; then
AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works,
@@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[
#endif
])
-gcc_AC_CHECK_DECLS(mallinfo, , ,[
+gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[
#include "ansidecl.h"
#include "system.h"
#ifdef HAVE_MALLOC_H
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 94da02f1185..f6be5472bd5 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void)
}
}
-/* Return memory used by heap in kb, 0 if this info is not available. */
+/* Print memory used by heap in MiB if this info is not available. */
void
report_heap_memory_use ()
{
-#ifdef HAVE_MALLINFO
+#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
+#ifdef HAVE_MALLINFO2
+ #define MALLINFO_FN mallinfo2
+#else
+ #define MALLINFO_FN mallinfo
+#endif
if (!quiet_flag)
- fprintf (stderr," {heap %luk}", (unsigned long)(mallinfo().arena / 1024));
+ fprintf (stderr," {heap %lu MiB}",
+ (unsigned long) MALLINFO_FN ().arena / ONE_M);
#endif
}
diff --git a/gcc/system.h b/gcc/system.h
index 3c543a005d8..4f0482be25d 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -732,7 +732,7 @@ extern int vsnprintf (char *, size_t, const char *, va_list);
#endif
#ifdef INCLUDE_MALLOC_H
-#ifdef HAVE_MALLINFO
+#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
#include <malloc.h>
#endif
#endif
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
@ 2020-09-01 12:32 ` Martin Liška
2020-09-01 14:04 ` Jan Hubicka
2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška
` (2 subsequent siblings)
3 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-01 12:32 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
The patch is about usage of MiB in memory allocation reports.
I see it much better readable than values displayed in KiB:
Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
Reading the symbol table:
Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
Merging symbols: {heap 15 MiB}Materializing decls:
<odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
Thoughts?
Thanks,
Martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 3/3] Use more ONE_? in GGC functions.
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
@ 2020-09-01 12:33 ` Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška
2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška
3 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-01 12:33 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 78 bytes --]
The last patch is a refactoring using ONE_* macros.
Thoughts?
Thanks,
Martin
[-- Attachment #2: 0003-Use-more-ONE_-in-GGC-functions.patch --]
[-- Type: text/x-patch, Size: 3836 bytes --]
From 999a1969e7325efa0072d0ee893fcb6aa7178997 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Tue, 1 Sep 2020 14:24:20 +0200
Subject: [PATCH 3/3] Use more ONE_? in GGC functions.
gcc/ChangeLog:
* ggc-common.c (ggc_rlimit_bound): Use ONE_? macros.
(ggc_min_expand_heuristic): Likewise.
(ggc_min_heapsize_heuristic): Likewise.
* ggc-page.c (ggc_collect): Likewise.
* system.h (ONE_G): Likewise.
---
gcc/ggc-common.c | 16 ++++++++--------
gcc/ggc-page.c | 2 +-
gcc/system.h | 1 +
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index f6be5472bd5..a22f746e645 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -742,7 +742,7 @@ ggc_rlimit_bound (double limit)
appears to be ignored. Ignore such silliness. If a limit
this small was actually effective for mmap, GCC wouldn't even
start up. */
- && rlim.rlim_cur >= 8 * 1024 * 1024)
+ && rlim.rlim_cur >= 8 * ONE_M)
limit = rlim.rlim_cur;
# endif /* RLIMIT_AS or RLIMIT_DATA */
#endif /* HAVE_GETRLIMIT */
@@ -761,7 +761,7 @@ ggc_min_expand_heuristic (void)
/* The heuristic is a percentage equal to 30% + 70%*(RAM/1GB), yielding
a lower bound of 30% and an upper bound of 100% (when RAM >= 1GB). */
- min_expand /= 1024*1024*1024;
+ min_expand /= ONE_G;
min_expand *= 70;
min_expand = MIN (min_expand, 70);
min_expand += 30;
@@ -776,8 +776,8 @@ ggc_min_heapsize_heuristic (void)
double phys_kbytes = physmem_total ();
double limit_kbytes = ggc_rlimit_bound (phys_kbytes * 2);
- phys_kbytes /= 1024; /* Convert to Kbytes. */
- limit_kbytes /= 1024;
+ phys_kbytes /= ONE_K; /* Convert to Kbytes. */
+ limit_kbytes /= ONE_K;
/* The heuristic is RAM/8, with a lower bound of 4M and an upper
bound of 128M (when RAM >= 1GB). */
@@ -790,7 +790,7 @@ ggc_min_heapsize_heuristic (void)
struct rlimit rlim;
if (getrlimit (RLIMIT_RSS, &rlim) == 0
&& rlim.rlim_cur != (rlim_t) RLIM_INFINITY)
- phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / 1024);
+ phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / ONE_K);
}
# endif
@@ -798,12 +798,12 @@ ggc_min_heapsize_heuristic (void)
*next* GC would be within 20Mb of the limit or within a quarter of
the limit, whichever is larger. If GCC does hit the data limit,
compilation will fail, so this tries to be conservative. */
- limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * 1024));
+ limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * ONE_K));
limit_kbytes = (limit_kbytes * 100) / (110 + ggc_min_expand_heuristic ());
phys_kbytes = MIN (phys_kbytes, limit_kbytes);
- phys_kbytes = MAX (phys_kbytes, 4 * 1024);
- phys_kbytes = MIN (phys_kbytes, 128 * 1024);
+ phys_kbytes = MAX (phys_kbytes, 4 * ONE_K);
+ phys_kbytes = MIN (phys_kbytes, 128 * ONE_K);
return phys_kbytes;
}
diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c
index 0a43a7cdc0e..e5988ab1839 100644
--- a/gcc/ggc-page.c
+++ b/gcc/ggc-page.c
@@ -2184,7 +2184,7 @@ ggc_collect (void)
total allocations haven't expanded much since the last
collection. */
float allocated_last_gc =
- MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * 1024);
+ MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * ONE_K);
/* It is also good time to get memory block pool into limits. */
memory_block_pool::trim ();
diff --git a/gcc/system.h b/gcc/system.h
index 4f0482be25d..b0f3f1dd019 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1237,6 +1237,7 @@ void gcc_stablesort (void *, size_t, size_t,
#define ONE_K 1024
#define ONE_M (ONE_K * ONE_K)
+#define ONE_G (ONE_K * ONE_M)
/* Display a number as an integer multiple of either:
- 1024, if said integer is >= to 10 K (in base 2)
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 4/N] Change timevar memory allocation to MiB.
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška
@ 2020-09-01 13:38 ` Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška
3 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-01 13:38 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]
And there's one more piece needed for -ftime-report:
Time variable usr sys wall GGC
phase setup : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 1%) 2 MiB ( 6%)
phase opt and generate : 0.25 ( 40%) 0.02 ( 25%) 0.26 ( 37%) 0 MiB ( 1%)
phase stream in : 0.18 ( 29%) 0.02 ( 25%) 0.20 ( 29%) 30 MiB ( 93%)
phase stream out : 0.19 ( 31%) 0.04 ( 50%) 0.23 ( 33%) 0 MiB ( 0%)
garbage collection : 0.03 ( 5%) 0.00 ( 0%) 0.03 ( 4%) 0 MiB ( 0%)
callgraph optimization : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 3%) 0 MiB ( 0%)
ipa ODR types : 0.00 ( 0%) 0.01 ( 12%) 0.00 ( 0%) 0 MiB ( 0%)
ipa function summary : 0.01 ( 2%) 0.00 ( 0%) 0.00 ( 0%) 2 MiB ( 8%)
ipa dead code removal : 0.03 ( 5%) 0.00 ( 0%) 0.03 ( 4%) 0 MiB ( 0%)
ipa cp : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
ipa inlining heuristics : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
lto stream decompression : 0.01 ( 2%) 0.00 ( 0%) 0.00 ( 0%) 0 MiB ( 0%)
ipa lto gimple out : 0.06 ( 10%) 0.01 ( 13%) 0.07 ( 10%) 0 MiB ( 0%)
ipa lto decl in : 0.07 ( 11%) 0.01 ( 12%) 0.08 ( 11%) 18 MiB ( 57%)
ipa lto decl out : 0.12 ( 19%) 0.00 ( 0%) 0.12 ( 17%) 0 MiB ( 0%)
ipa lto cgraph I/O : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 8 MiB ( 27%)
ipa lto decl merge : 0.04 ( 6%) 0.00 ( 0%) 0.04 ( 6%) 0 MiB ( 2%)
whopr wpa I/O : 0.01 ( 2%) 0.03 ( 38%) 0.04 ( 6%) 0 MiB ( 0%)
whopr partitioning : 0.04 ( 6%) 0.00 ( 0%) 0.04 ( 6%) 0 MiB ( 1%)
ipa reference : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
ipa profile : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
ipa pure const : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
ipa SRA : 0.01 ( 2%) 0.00 ( 0%) 0.01 ( 1%) 0 MiB ( 0%)
callgraph verifier : 0.12 ( 19%) 0.02 ( 25%) 0.14 ( 20%) 0 MiB ( 0%)
TOTAL : 0.62 0.08 0.70 32 MiB
Martin
[-- Attachment #2: 0001-Change-timevar-memory-allocation-to-MiB.patch --]
[-- Type: text/x-patch, Size: 2668 bytes --]
From e177610161e8ec22fee70bb2339195b5104bd30e Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Tue, 1 Sep 2020 14:44:40 +0200
Subject: [PATCH] Change timevar memory allocation to MiB.
gcc/ChangeLog:
* timevar.c (timer::print): Print memory allocation in MiB.
gcc/testsuite/ChangeLog:
* g++.dg/ext/timevar1.C: Expect values in MiB.
* g++.dg/ext/timevar2.C: Likewise.
---
gcc/testsuite/g++.dg/ext/timevar1.C | 2 +-
gcc/testsuite/g++.dg/ext/timevar2.C | 2 +-
gcc/timevar.c | 8 ++++----
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/g++.dg/ext/timevar1.C b/gcc/testsuite/g++.dg/ext/timevar1.C
index 3f891a50aba..d810ebe3451 100644
--- a/gcc/testsuite/g++.dg/ext/timevar1.C
+++ b/gcc/testsuite/g++.dg/ext/timevar1.C
@@ -2,7 +2,7 @@
// { dg-options "-ftime-report" }
// { dg-allow-blank-lines-in-output 1 }
// { dg-prune-output "Time variable" }
-// { dg-prune-output " kB" }
+// { dg-prune-output " MiB" }
// { dg-prune-output "checks" }
void
diff --git a/gcc/testsuite/g++.dg/ext/timevar2.C b/gcc/testsuite/g++.dg/ext/timevar2.C
index dd96d45c01e..fa68aac7e72 100644
--- a/gcc/testsuite/g++.dg/ext/timevar2.C
+++ b/gcc/testsuite/g++.dg/ext/timevar2.C
@@ -1,7 +1,7 @@
// PR c++/57524
// { dg-options "-ftime-report" }
// { dg-prune-output "Time variable" }
-// { dg-prune-output " kB" }
+// { dg-prune-output " MiB" }
// { dg-prune-output "checks" }
namespace detail {
diff --git a/gcc/timevar.c b/gcc/timevar.c
index a3a882d3204..43b17571da2 100644
--- a/gcc/timevar.c
+++ b/gcc/timevar.c
@@ -661,8 +661,8 @@ timer::print_row (FILE *fp,
#endif /* HAVE_WALL_TIME */
/* Print the amount of ggc memory allocated. */
- fprintf (fp, "%8u kB (%3.0f%%)",
- (unsigned) (elapsed.ggc_mem >> 10),
+ fprintf (fp, "%8u MiB (%3.0f%%)",
+ (unsigned ) (elapsed.ggc_mem / ONE_M),
(total->ggc_mem == 0
? 0
: (float) elapsed.ggc_mem / total->ggc_mem) * 100);
@@ -712,7 +712,7 @@ timer::print (FILE *fp)
TIMEVAR. */
m_start_time = now;
- fprintf (fp, "\n%-35s%16s%14s%14s%18s\n", "Time variable", "usr", "sys",
+ fprintf (fp, "\n%-35s%16s%14s%14s%19s\n", "Time variable", "usr", "sys",
"wall", "GGC");
if (m_jit_client_items)
fputs ("GCC items:\n", fp);
@@ -776,7 +776,7 @@ timer::print (FILE *fp)
#ifdef HAVE_WALL_TIME
fprintf (fp, "%8.2f ", total->wall);
#endif
- fprintf (fp, "%9u kB\n", (unsigned) (total->ggc_mem >> 10));
+ fprintf (fp, "%9u MiB\n", (unsigned) (total->ggc_mem / ONE_M));
if (CHECKING_P || flag_checking)
fprintf (fp, "Extra diagnostic checks enabled; compiler may run slowly.\n");
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
@ 2020-09-01 14:04 ` Jan Hubicka
2020-09-02 13:28 ` Martin Liška
0 siblings, 1 reply; 16+ messages in thread
From: Jan Hubicka @ 2020-09-01 14:04 UTC (permalink / raw)
To: Martin Liška; +Cc: GCC Patches
> The patch is about usage of MiB in memory allocation reports.
> I see it much better readable than values displayed in KiB:
>
> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
> Reading the symbol table:
> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> Merging symbols: {heap 15 MiB}Materializing decls:
> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
One problem I see here is that while it is OK for Firefox builds it is
bit too coarse for smaller testcases where the memory use is still
importnat. I guess we may just print KBs before the large gets too
large, just like norton commander does? :)
Honza
>
> Thoughts?
> Thanks,
> Martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] Support new mallinfo2 function.
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
` (2 preceding siblings ...)
2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška
@ 2020-09-02 13:28 ` Martin Liška
2020-09-17 21:56 ` Jeff Law
3 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-02 13:28 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 458 bytes --]
On 9/1/20 2:31 PM, Martin Liška wrote:
> Hey.
>
> I've just applied to patches to glibc introducing a new mallinfo2 function.
> Limitation of the current function mallinfo is usage of int type which overflows
> for allocation > 2GB.
>
> The patch adds configure detection and usage of the new one. And it prints heap usage
> in MiB.
>
> Ready to be installed after tests?
> Thanks,
> Martin
All right, there's V2 where I just support mallinfo2.
Martin
[-- Attachment #2: 0001-Support-new-mallinfo2-function.patch --]
[-- Type: text/x-patch, Size: 4671 bytes --]
From bdb6dcf8fbd51a9dc62e6a50a7eeedc734c130f9 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Tue, 1 Sep 2020 14:14:45 +0200
Subject: [PATCH 1/3] Support new mallinfo2 function.
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Likewise.
* configure.ac: Detect for mallinfo2.
* ggc-common.c (defined): Use it.
* system.h: Handle also HAVE_MALLINFO2.
---
gcc/config.in | 16 ++++++++++++++--
gcc/configure | 4 ++--
gcc/configure.ac | 4 ++--
gcc/ggc-common.c | 12 +++++++++---
gcc/system.h | 2 +-
5 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/gcc/config.in b/gcc/config.in
index 478e74fac02..1832c112ed9 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -983,13 +983,19 @@
#endif
-/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to
- 0. */
+/* Define to 1 if we found a declaration for 'mallinfo */
#ifndef USED_FOR_TARGET
#undef HAVE_DECL_MALLINFO
#endif
+/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to
+ 0. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_DECL_MALLINFO2
+#endif
+
+
/* Define to 1 if we found a declaration for 'malloc', otherwise define to 0.
*/
#ifndef USED_FOR_TARGET
@@ -1665,6 +1671,12 @@
#endif
+/* Define to 1 if you have the `mallinfo2' function. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_MALLINFO2
+#endif
+
+
/* Define to 1 if you have the <malloc.h> header file. */
#ifndef USED_FOR_TARGET
#undef HAVE_MALLOC_H
diff --git a/gcc/configure b/gcc/configure
index 0f7a8dbe0f9..b8b9bd3505b 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -10120,7 +10120,7 @@ fi
for ac_func in times clock kill getrlimit setrlimit atoq \
popen sysconf strsignal getrusage nl_langinfo \
gettimeofday mbstowcs wcswidth mmap setlocale \
- clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo
+ clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2
do :
as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var"
@@ -11549,7 +11549,7 @@ fi
done
-for ac_func in mallinfo
+for ac_func in mallinfo, mallinfo2
do
ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp`
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0f11238c19f..18640fdb8a5 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl
AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \
popen sysconf strsignal getrusage nl_langinfo \
gettimeofday mbstowcs wcswidth mmap setlocale \
- gcc_UNLOCKED_FUNCS madvise mallinfo)
+ gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2)
if test x$ac_cv_func_mbstowcs = xyes; then
AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works,
@@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[
#endif
])
-gcc_AC_CHECK_DECLS(mallinfo, , ,[
+gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[
#include "ansidecl.h"
#include "system.h"
#ifdef HAVE_MALLOC_H
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 94da02f1185..b8782c5824b 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void)
}
}
-/* Return memory used by heap in kb, 0 if this info is not available. */
+/* Print memory used by heap in kb if this info is not available. */
void
report_heap_memory_use ()
{
-#ifdef HAVE_MALLINFO
+#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
+#ifdef HAVE_MALLINFO2
+ #define MALLINFO_FN mallinfo2
+#else
+ #define MALLINFO_FN mallinfo
+#endif
if (!quiet_flag)
- fprintf (stderr," {heap %luk}", (unsigned long)(mallinfo().arena / 1024));
+ fprintf (stderr," {heap %luk}",
+ (unsigned long) MALLINFO_FN ().arena / ONE_K);
#endif
}
diff --git a/gcc/system.h b/gcc/system.h
index 3c543a005d8..4f0482be25d 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -732,7 +732,7 @@ extern int vsnprintf (char *, size_t, const char *, va_list);
#endif
#ifdef INCLUDE_MALLOC_H
-#ifdef HAVE_MALLINFO
+#if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
#include <malloc.h>
#endif
#endif
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-01 14:04 ` Jan Hubicka
@ 2020-09-02 13:28 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
2020-09-22 7:47 ` Christophe Lyon
0 siblings, 2 replies; 16+ messages in thread
From: Martin Liška @ 2020-09-02 13:28 UTC (permalink / raw)
To: Jan Hubicka; +Cc: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
On 9/1/20 4:04 PM, Jan Hubicka wrote:
>> The patch is about usage of MiB in memory allocation reports.
>> I see it much better readable than values displayed in KiB:
>>
>> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
>> Reading the symbol table:
>> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
>> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
>> Merging symbols: {heap 15 MiB}Materializing decls:
>> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
>> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
>
> One problem I see here is that while it is OK for Firefox builds it is
> bit too coarse for smaller testcases where the memory use is still
> importnat. I guess we may just print KBs before the large gets too
> large, just like norton commander does? :)
Sure, let's do it using SIZE_AMOUNT macro.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>
> Honza
>>
>> Thoughts?
>> Thanks,
>> Martin
[-- Attachment #2: 0002-Use-SIZE_AMOUNT-macro-for-GGC-memory-allocation-numb.patch --]
[-- Type: text/x-patch, Size: 5616 bytes --]
From 8826f267175d456121612332b838e41a9542a513 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Wed, 2 Sep 2020 14:30:16 +0200
Subject: [PATCH 2/3] Use SIZE_AMOUNT macro for GGC memory allocation numbers.
gcc/ChangeLog:
* ggc-common.c (ggc_prune_overhead_list): Use SIZE_AMOUNT.
* ggc-page.c (release_pages): Likewise.
(ggc_collect): Likewise.
(ggc_trim): Likewise.
(ggc_grow): Likewise.
* timevar.c (timer::print): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/ext/timevar1.C: Prune more possible number values.
* g++.dg/ext/timevar2.C: Likewise.
---
gcc/ggc-common.c | 6 +++---
gcc/ggc-page.c | 15 +++++++--------
gcc/testsuite/g++.dg/ext/timevar1.C | 3 ++-
gcc/testsuite/g++.dg/ext/timevar2.C | 3 ++-
gcc/timevar.c | 8 ++++----
5 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index b8782c5824b..50c52fe525b 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -1008,7 +1008,7 @@ ggc_prune_overhead_list (void)
}
}
-/* Print memory used by heap in kb if this info is not available. */
+/* Print memory used by heap if this info is not available. */
void
report_heap_memory_use ()
@@ -1020,7 +1020,7 @@ report_heap_memory_use ()
#define MALLINFO_FN mallinfo
#endif
if (!quiet_flag)
- fprintf (stderr," {heap %luk}",
- (unsigned long) MALLINFO_FN ().arena / ONE_K);
+ fprintf (stderr, " {heap " PRsa (0) "}",
+ SIZE_AMOUNT (MALLINFO_FN ().arena));
#endif
}
diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c
index 53b311c2a52..9405f033a7c 100644
--- a/gcc/ggc-page.c
+++ b/gcc/ggc-page.c
@@ -1164,9 +1164,9 @@ release_pages (void)
{
fprintf (stderr, " {GC");
if (n1)
- fprintf (stderr, " released %luk", (unsigned long)(n1 / 1024));
+ fprintf (stderr, " released " PRsa (0), SIZE_AMOUNT (n1));
if (n2)
- fprintf (stderr, " madv_dontneed %luk", (unsigned long)(n2 / 1024));
+ fprintf (stderr, " madv_dontneed " PRsa (0), SIZE_AMOUNT (n2));
fprintf (stderr, "}");
}
}
@@ -2208,7 +2208,7 @@ ggc_collect (void)
/* Output this later so we do not interfere with release_pages. */
if (!quiet_flag)
- fprintf (stderr, " {GC %luk -> ", (unsigned long) allocated / 1024);
+ fprintf (stderr, " {GC " PRsa (0) " -> ", SIZE_AMOUNT (allocated));
/* Indicate that we've seen collections at this context depth. */
G.context_depth_collections = ((unsigned long)1 << (G.context_depth + 1)) - 1;
@@ -2235,7 +2235,7 @@ ggc_collect (void)
timevar_pop (TV_GC);
if (!quiet_flag)
- fprintf (stderr, "%luk}", (unsigned long) G.allocated / 1024);
+ fprintf (stderr, PRsa (0) "}", SIZE_AMOUNT (G.allocated));
if (GGC_DEBUG_LEVEL >= 2)
fprintf (G.debug_file, "END COLLECTING\n");
}
@@ -2250,9 +2250,8 @@ ggc_trim ()
sweep_pages ();
release_pages ();
if (!quiet_flag)
- fprintf (stderr, " {GC trimmed to %luk, %luk mapped}",
- (unsigned long) G.allocated / 1024,
- (unsigned long) G.bytes_mapped / 1024);
+ fprintf (stderr, " {GC trimmed to " PRsa (0) ", " PRsa (0) " mapped}",
+ SIZE_AMOUNT (G.allocated), SIZE_AMOUNT (G.bytes_mapped));
timevar_pop (TV_GC);
}
@@ -2269,7 +2268,7 @@ ggc_grow (void)
else
ggc_collect ();
if (!quiet_flag)
- fprintf (stderr, " {GC %luk} ", (unsigned long) G.allocated / 1024);
+ fprintf (stderr, " {GC " PRsa (0) "} ", SIZE_AMOUNT (G.allocated));
}
void
diff --git a/gcc/testsuite/g++.dg/ext/timevar1.C b/gcc/testsuite/g++.dg/ext/timevar1.C
index 3f891a50aba..988a6f8543d 100644
--- a/gcc/testsuite/g++.dg/ext/timevar1.C
+++ b/gcc/testsuite/g++.dg/ext/timevar1.C
@@ -2,7 +2,8 @@
// { dg-options "-ftime-report" }
// { dg-allow-blank-lines-in-output 1 }
// { dg-prune-output "Time variable" }
-// { dg-prune-output " kB" }
+// { dg-prune-output "k" }
+// { dg-prune-output " 0 " }
// { dg-prune-output "checks" }
void
diff --git a/gcc/testsuite/g++.dg/ext/timevar2.C b/gcc/testsuite/g++.dg/ext/timevar2.C
index dd96d45c01e..46c3e1b4794 100644
--- a/gcc/testsuite/g++.dg/ext/timevar2.C
+++ b/gcc/testsuite/g++.dg/ext/timevar2.C
@@ -1,7 +1,8 @@
// PR c++/57524
// { dg-options "-ftime-report" }
// { dg-prune-output "Time variable" }
-// { dg-prune-output " kB" }
+// { dg-prune-output "k" }
+// { dg-prune-output " 0 " }
// { dg-prune-output "checks" }
namespace detail {
diff --git a/gcc/timevar.c b/gcc/timevar.c
index a3a882d3204..8fbf5faa4e3 100644
--- a/gcc/timevar.c
+++ b/gcc/timevar.c
@@ -661,8 +661,8 @@ timer::print_row (FILE *fp,
#endif /* HAVE_WALL_TIME */
/* Print the amount of ggc memory allocated. */
- fprintf (fp, "%8u kB (%3.0f%%)",
- (unsigned) (elapsed.ggc_mem >> 10),
+ fprintf (fp, PRsa (6) " (%3.0f%%)",
+ SIZE_AMOUNT (elapsed.ggc_mem),
(total->ggc_mem == 0
? 0
: (float) elapsed.ggc_mem / total->ggc_mem) * 100);
@@ -712,7 +712,7 @@ timer::print (FILE *fp)
TIMEVAR. */
m_start_time = now;
- fprintf (fp, "\n%-35s%16s%14s%14s%18s\n", "Time variable", "usr", "sys",
+ fprintf (fp, "\n%-35s%16s%14s%14s%14s\n", "Time variable", "usr", "sys",
"wall", "GGC");
if (m_jit_client_items)
fputs ("GCC items:\n", fp);
@@ -776,7 +776,7 @@ timer::print (FILE *fp)
#ifdef HAVE_WALL_TIME
fprintf (fp, "%8.2f ", total->wall);
#endif
- fprintf (fp, "%9u kB\n", (unsigned) (total->ggc_mem >> 10));
+ fprintf (fp, PRsa (7) "\n", SIZE_AMOUNT (total->ggc_mem));
if (CHECKING_P || flag_checking)
fprintf (fp, "Extra diagnostic checks enabled; compiler may run slowly.\n");
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 4/N] Change timevar memory allocation to MiB.
2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška
@ 2020-09-02 13:29 ` Martin Liška
0 siblings, 0 replies; 16+ messages in thread
From: Martin Liška @ 2020-09-02 13:29 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
Please forget about the patch. It's part of 02/N v2.
Martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] Use more ONE_? in GGC functions.
2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška
@ 2020-09-02 13:29 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
0 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-02 13:29 UTC (permalink / raw)
To: GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
On 9/1/20 2:33 PM, Martin Liška wrote:
> The last patch is a refactoring using ONE_* macros.
>
> Thoughts?
> Thanks,
> Martin
There's rebassed version of the patch.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
[-- Attachment #2: 0003-Use-ONE_-macros.patch --]
[-- Type: text/x-patch, Size: 3820 bytes --]
From 5cefff607077503794a387b612585604c2b3d0f0 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Wed, 2 Sep 2020 14:34:21 +0200
Subject: [PATCH 3/3] Use ONE_? macros.
gcc/ChangeLog:
* ggc-common.c (ggc_rlimit_bound): Use ONE_? macro.
(ggc_min_expand_heuristic): Likewise.
(ggc_min_heapsize_heuristic): Likewise.
* ggc-page.c (ggc_collect): Likewise.
* system.h (ONE_G): Likewise.
---
gcc/ggc-common.c | 16 ++++++++--------
gcc/ggc-page.c | 2 +-
gcc/system.h | 1 +
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 50c52fe525b..c21886861f0 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -742,7 +742,7 @@ ggc_rlimit_bound (double limit)
appears to be ignored. Ignore such silliness. If a limit
this small was actually effective for mmap, GCC wouldn't even
start up. */
- && rlim.rlim_cur >= 8 * 1024 * 1024)
+ && rlim.rlim_cur >= 8 * ONE_M)
limit = rlim.rlim_cur;
# endif /* RLIMIT_AS or RLIMIT_DATA */
#endif /* HAVE_GETRLIMIT */
@@ -761,7 +761,7 @@ ggc_min_expand_heuristic (void)
/* The heuristic is a percentage equal to 30% + 70%*(RAM/1GB), yielding
a lower bound of 30% and an upper bound of 100% (when RAM >= 1GB). */
- min_expand /= 1024*1024*1024;
+ min_expand /= ONE_G;
min_expand *= 70;
min_expand = MIN (min_expand, 70);
min_expand += 30;
@@ -776,8 +776,8 @@ ggc_min_heapsize_heuristic (void)
double phys_kbytes = physmem_total ();
double limit_kbytes = ggc_rlimit_bound (phys_kbytes * 2);
- phys_kbytes /= 1024; /* Convert to Kbytes. */
- limit_kbytes /= 1024;
+ phys_kbytes /= ONE_K; /* Convert to Kbytes. */
+ limit_kbytes /= ONE_K;
/* The heuristic is RAM/8, with a lower bound of 4M and an upper
bound of 128M (when RAM >= 1GB). */
@@ -790,7 +790,7 @@ ggc_min_heapsize_heuristic (void)
struct rlimit rlim;
if (getrlimit (RLIMIT_RSS, &rlim) == 0
&& rlim.rlim_cur != (rlim_t) RLIM_INFINITY)
- phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / 1024);
+ phys_kbytes = MIN (phys_kbytes, rlim.rlim_cur / ONE_K);
}
# endif
@@ -798,12 +798,12 @@ ggc_min_heapsize_heuristic (void)
*next* GC would be within 20Mb of the limit or within a quarter of
the limit, whichever is larger. If GCC does hit the data limit,
compilation will fail, so this tries to be conservative. */
- limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * 1024));
+ limit_kbytes = MAX (0, limit_kbytes - MAX (limit_kbytes / 4, 20 * ONE_K));
limit_kbytes = (limit_kbytes * 100) / (110 + ggc_min_expand_heuristic ());
phys_kbytes = MIN (phys_kbytes, limit_kbytes);
- phys_kbytes = MAX (phys_kbytes, 4 * 1024);
- phys_kbytes = MIN (phys_kbytes, 128 * 1024);
+ phys_kbytes = MAX (phys_kbytes, 4 * ONE_K);
+ phys_kbytes = MIN (phys_kbytes, 128 * ONE_K);
return phys_kbytes;
}
diff --git a/gcc/ggc-page.c b/gcc/ggc-page.c
index 9405f033a7c..07e108f3e9d 100644
--- a/gcc/ggc-page.c
+++ b/gcc/ggc-page.c
@@ -2184,7 +2184,7 @@ ggc_collect (void)
total allocations haven't expanded much since the last
collection. */
float allocated_last_gc =
- MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * 1024);
+ MAX (G.allocated_last_gc, (size_t)param_ggc_min_heapsize * ONE_K);
/* It is also good time to get memory block pool into limits. */
memory_block_pool::trim ();
diff --git a/gcc/system.h b/gcc/system.h
index 4f0482be25d..b0f3f1dd019 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1237,6 +1237,7 @@ void gcc_stablesort (void *, size_t, size_t,
#define ONE_K 1024
#define ONE_M (ONE_K * ONE_K)
+#define ONE_G (ONE_K * ONE_M)
/* Display a number as an integer multiple of either:
- 1024, if said integer is >= to 10 K (in base 2)
--
2.28.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] Support new mallinfo2 function.
2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška
@ 2020-09-17 21:56 ` Jeff Law
0 siblings, 0 replies; 16+ messages in thread
From: Jeff Law @ 2020-09-17 21:56 UTC (permalink / raw)
To: Martin Liška, GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 4899 bytes --]
On 9/2/20 7:28 AM, Martin Liška wrote:
> On 9/1/20 2:31 PM, Martin Liška wrote:
>> Hey.
>>
>> I've just applied to patches to glibc introducing a new mallinfo2
>> function.
>> Limitation of the current function mallinfo is usage of int type
>> which overflows
>> for allocation > 2GB.
>>
>> The patch adds configure detection and usage of the new one. And it
>> prints heap usage
>> in MiB.
>>
>> Ready to be installed after tests?
>> Thanks,
>> Martin
>
> All right, there's V2 where I just support mallinfo2.
>
> Martin
>
> 0001-Support-new-mallinfo2-function.patch
>
> From bdb6dcf8fbd51a9dc62e6a50a7eeedc734c130f9 Mon Sep 17 00:00:00 2001
> From: Martin Liska <mliska@suse.cz>
> Date: Tue, 1 Sep 2020 14:14:45 +0200
> Subject: [PATCH 1/3] Support new mallinfo2 function.
>
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * configure: Likewise.
> * configure.ac: Detect for mallinfo2.
> * ggc-common.c (defined): Use it.
> * system.h: Handle also HAVE_MALLINFO2.
> ---
> gcc/config.in | 16 ++++++++++++++--
> gcc/configure | 4 ++--
> gcc/configure.ac | 4 ++--
> gcc/ggc-common.c | 12 +++++++++---
> gcc/system.h | 2 +-
> 5 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/gcc/config.in b/gcc/config.in
> index 478e74fac02..1832c112ed9 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -983,13 +983,19 @@
> #endif
>
>
> -/* Define to 1 if we found a declaration for 'mallinfo', otherwise define to
> - 0. */
> +/* Define to 1 if we found a declaration for 'mallinfo */
> #ifndef USED_FOR_TARGET
> #undef HAVE_DECL_MALLINFO
> #endif
>
>
> +/* Define to 1 if we found a declaration for 'mallinfo2', otherwise define to
> + 0. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_DECL_MALLINFO2
> +#endif
> +
> +
> /* Define to 1 if we found a declaration for 'malloc', otherwise define to 0.
> */
> #ifndef USED_FOR_TARGET
> @@ -1665,6 +1671,12 @@
> #endif
>
>
> +/* Define to 1 if you have the `mallinfo2' function. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_MALLINFO2
> +#endif
> +
> +
> /* Define to 1 if you have the <malloc.h> header file. */
> #ifndef USED_FOR_TARGET
> #undef HAVE_MALLOC_H
> diff --git a/gcc/configure b/gcc/configure
> index 0f7a8dbe0f9..b8b9bd3505b 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -10120,7 +10120,7 @@ fi
> for ac_func in times clock kill getrlimit setrlimit atoq \
> popen sysconf strsignal getrusage nl_langinfo \
> gettimeofday mbstowcs wcswidth mmap setlocale \
> - clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo
> + clearerr_unlocked feof_unlocked ferror_unlocked fflush_unlocked fgetc_unlocked fgets_unlocked fileno_unlocked fprintf_unlocked fputc_unlocked fputs_unlocked fread_unlocked fwrite_unlocked getchar_unlocked getc_unlocked putchar_unlocked putc_unlocked madvise mallinfo mallinfo2
> do :
> as_ac_var=`$as_echo "ac_cv_func_$ac_func" | $as_tr_sh`
> ac_fn_cxx_check_func "$LINENO" "$ac_func" "$as_ac_var"
> @@ -11549,7 +11549,7 @@ fi
> done
>
>
> -for ac_func in mallinfo
> +for ac_func in mallinfo, mallinfo2
> do
> ac_tr_decl=`$as_echo "HAVE_DECL_$ac_func" | $as_tr_cpp`
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether $ac_func is declared" >&5
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 0f11238c19f..18640fdb8a5 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -1408,7 +1408,7 @@ define(gcc_UNLOCKED_FUNCS, clearerr_unlocked feof_unlocked dnl
> AC_CHECK_FUNCS(times clock kill getrlimit setrlimit atoq \
> popen sysconf strsignal getrusage nl_langinfo \
> gettimeofday mbstowcs wcswidth mmap setlocale \
> - gcc_UNLOCKED_FUNCS madvise mallinfo)
> + gcc_UNLOCKED_FUNCS madvise mallinfo mallinfo2)
>
> if test x$ac_cv_func_mbstowcs = xyes; then
> AC_CACHE_CHECK(whether mbstowcs works, gcc_cv_func_mbstowcs_works,
> @@ -1488,7 +1488,7 @@ gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[
> #endif
> ])
>
> -gcc_AC_CHECK_DECLS(mallinfo, , ,[
> +gcc_AC_CHECK_DECLS([mallinfo, mallinfo2], , ,[
> #include "ansidecl.h"
> #include "system.h"
> #ifdef HAVE_MALLOC_H
> diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
> index 94da02f1185..b8782c5824b 100644
> --- a/gcc/ggc-common.c
> +++ b/gcc/ggc-common.c
> @@ -1008,13 +1008,19 @@ ggc_prune_overhead_list (void)
> }
> }
>
> -/* Return memory used by heap in kb, 0 if this info is not available. */
> +/* Print memory used by heap in kb if this info is not available. */
This comment seems wrong... OK with the comment fixed.
jeff
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1763 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-02 13:28 ` Martin Liška
@ 2020-09-17 21:57 ` Jeff Law
2020-09-22 7:47 ` Christophe Lyon
1 sibling, 0 replies; 16+ messages in thread
From: Jeff Law @ 2020-09-17 21:57 UTC (permalink / raw)
To: Martin Liška, Jan Hubicka; +Cc: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 3545 bytes --]
On 9/2/20 7:28 AM, Martin Liška wrote:
> On 9/1/20 4:04 PM, Jan Hubicka wrote:
>>> The patch is about usage of MiB in memory allocation reports.
>>> I see it much better readable than values displayed in KiB:
>>>
>>> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB ->
>>> 19 MiB} {GC 19 MiB} {heap 12 MiB}
>>> Reading the symbol table:
>>> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27
>>> MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
>>> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB}
>>> <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB}
>>> {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB}
>>> {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const>
>>> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
>>> Merging symbols: {heap 15 MiB}Materializing decls:
>>> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB}
>>> <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap
>>> 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB}
>>> <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap
>>> 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC
>>> trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap
>>> 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
>>> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB}
>>> ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns)
>>> ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
>>
>> One problem I see here is that while it is OK for Firefox builds it is
>> bit too coarse for smaller testcases where the memory use is still
>> importnat. I guess we may just print KBs before the large gets too
>> large, just like norton commander does? :)
>
> Sure, let's do it using SIZE_AMOUNT macro.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
>>
>> Honza
>>>
>>> Thoughts?
>>> Thanks,
>>> Martin
>
>
> 0002-Use-SIZE_AMOUNT-macro-for-GGC-memory-allocation-numb.patch
>
> From 8826f267175d456121612332b838e41a9542a513 Mon Sep 17 00:00:00 2001
> From: Martin Liska <mliska@suse.cz>
> Date: Wed, 2 Sep 2020 14:30:16 +0200
> Subject: [PATCH 2/3] Use SIZE_AMOUNT macro for GGC memory allocation numbers.
>
> gcc/ChangeLog:
>
> * ggc-common.c (ggc_prune_overhead_list): Use SIZE_AMOUNT.
> * ggc-page.c (release_pages): Likewise.
> (ggc_collect): Likewise.
> (ggc_trim): Likewise.
> (ggc_grow): Likewise.
> * timevar.c (timer::print): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ext/timevar1.C: Prune more possible number values.
> * g++.dg/ext/timevar2.C: Likewise.
> ---
> gcc/ggc-common.c | 6 +++---
> gcc/ggc-page.c | 15 +++++++--------
> gcc/testsuite/g++.dg/ext/timevar1.C | 3 ++-
> gcc/testsuite/g++.dg/ext/timevar2.C | 3 ++-
> gcc/timevar.c | 8 ++++----
> 5 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
> index b8782c5824b..50c52fe525b 100644
> --- a/gcc/ggc-common.c
> +++ b/gcc/ggc-common.c
> @@ -1008,7 +1008,7 @@ ggc_prune_overhead_list (void)
> }
> }
>
> -/* Print memory used by heap in kb if this info is not available. */
> +/* Print memory used by heap if this info is not available. */
Seems like the same problem as the prior patch ;-)
OK with that nit fixed.
jeff
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1763 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] Use more ONE_? in GGC functions.
2020-09-02 13:29 ` Martin Liška
@ 2020-09-17 21:57 ` Jeff Law
0 siblings, 0 replies; 16+ messages in thread
From: Jeff Law @ 2020-09-17 21:57 UTC (permalink / raw)
To: Martin Liška, GCC Patches; +Cc: Jan Hubicka
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On 9/2/20 7:29 AM, Martin Liška wrote:
> On 9/1/20 2:33 PM, Martin Liška wrote:
>> The last patch is a refactoring using ONE_* macros.
>>
>> Thoughts?
>> Thanks,
>> Martin
>
> There's rebassed version of the patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> 0003-Use-ONE_-macros.patch
>
> From 5cefff607077503794a387b612585604c2b3d0f0 Mon Sep 17 00:00:00 2001
> From: Martin Liska <mliska@suse.cz>
> Date: Wed, 2 Sep 2020 14:34:21 +0200
> Subject: [PATCH 3/3] Use ONE_? macros.
>
> gcc/ChangeLog:
>
> * ggc-common.c (ggc_rlimit_bound): Use ONE_? macro.
> (ggc_min_expand_heuristic): Likewise.
> (ggc_min_heapsize_heuristic): Likewise.
> * ggc-page.c (ggc_collect): Likewise.
> * system.h (ONE_G): Likewise.
OK
jeff
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 1763 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-02 13:28 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
@ 2020-09-22 7:47 ` Christophe Lyon
2020-09-22 8:30 ` Martin Liška
1 sibling, 1 reply; 16+ messages in thread
From: Christophe Lyon @ 2020-09-22 7:47 UTC (permalink / raw)
To: Martin Liška; +Cc: Jan Hubicka, GCC Patches
On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote:
>
> On 9/1/20 4:04 PM, Jan Hubicka wrote:
> >> The patch is about usage of MiB in memory allocation reports.
> >> I see it much better readable than values displayed in KiB:
> >>
> >> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
> >> Reading the symbol table:
> >> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> >> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> >> Merging symbols: {heap 15 MiB}Materializing decls:
> >> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
> >> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
> >
> > One problem I see here is that while it is OK for Firefox builds it is
> > bit too coarse for smaller testcases where the memory use is still
> > importnat. I guess we may just print KBs before the large gets too
> > large, just like norton commander does? :)
>
> Sure, let's do it using SIZE_AMOUNT macro.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
Hi,
This change is causing gcc.dg/timevar[12].C to fail randomly, eg:
FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors)
Excess errors:
phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
0.01 ( 50%) 8904 ( 0%)
callgraph construction : 0.00 ( 0%) 0.00 ( 0%)
0.01 ( 50%) 4096 ( 0%)
because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests
now use dg-prune-output "k" and dg-prune-output " 0 "
which is not enough.
Can you fix this?
Thanks
Christophe
> Ready to be installed?
> Thanks,
> Martin
>
> >
> > Honza
> >>
> >> Thoughts?
> >> Thanks,
> >> Martin
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-22 7:47 ` Christophe Lyon
@ 2020-09-22 8:30 ` Martin Liška
2020-09-22 13:02 ` Marek Polacek
0 siblings, 1 reply; 16+ messages in thread
From: Martin Liška @ 2020-09-22 8:30 UTC (permalink / raw)
To: Christophe Lyon; +Cc: Jan Hubicka, GCC Patches, Marek Polacek
On 9/22/20 9:47 AM, Christophe Lyon wrote:
> On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote:
>>
>> On 9/1/20 4:04 PM, Jan Hubicka wrote:
>>>> The patch is about usage of MiB in memory allocation reports.
>>>> I see it much better readable than values displayed in KiB:
>>>>
>>>> Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
>>>> Reading the symbol table:
>>>> Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
>>>> Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
>>>> Merging symbols: {heap 15 MiB}Materializing decls:
>>>> <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
>>>> Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
>>>
>>> One problem I see here is that while it is OK for Firefox builds it is
>>> bit too coarse for smaller testcases where the memory use is still
>>> importnat. I guess we may just print KBs before the large gets too
>>> large, just like norton commander does? :)
>>
>> Sure, let's do it using SIZE_AMOUNT macro.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>
> Hi,
>
> This change is causing gcc.dg/timevar[12].C to fail randomly, eg:
> FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors)
> Excess errors:
> phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
> 0.01 ( 50%) 8904 ( 0%)
> callgraph construction : 0.00 ( 0%) 0.00 ( 0%)
> 0.01 ( 50%) 4096 ( 0%)
>
> because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests
> now use dg-prune-output "k" and dg-prune-output " 0 "
> which is not enough.
>
> Can you fix this?
Sorry for the breakage. I hope Marek has a fix that he'll install.
Martin
>
> Thanks
>
> Christophe
>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>>>
>>> Honza
>>>>
>>>> Thoughts?
>>>> Thanks,
>>>> Martin
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-22 8:30 ` Martin Liška
@ 2020-09-22 13:02 ` Marek Polacek
2020-09-22 13:24 ` Marek Polacek
0 siblings, 1 reply; 16+ messages in thread
From: Marek Polacek @ 2020-09-22 13:02 UTC (permalink / raw)
To: Martin Liška; +Cc: Christophe Lyon, GCC Patches, Jan Hubicka
On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote:
> On 9/22/20 9:47 AM, Christophe Lyon wrote:
> > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote:
> > >
> > > On 9/1/20 4:04 PM, Jan Hubicka wrote:
> > > > > The patch is about usage of MiB in memory allocation reports.
> > > > > I see it much better readable than values displayed in KiB:
> > > > >
> > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
> > > > > Reading the symbol table:
> > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> > > > > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> > > > > Merging symbols: {heap 15 MiB}Materializing decls:
> > > > > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
> > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
> > > >
> > > > One problem I see here is that while it is OK for Firefox builds it is
> > > > bit too coarse for smaller testcases where the memory use is still
> > > > importnat. I guess we may just print KBs before the large gets too
> > > > large, just like norton commander does? :)
> > >
> > > Sure, let's do it using SIZE_AMOUNT macro.
> > >
> > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > >
> >
> > Hi,
> >
> > This change is causing gcc.dg/timevar[12].C to fail randomly, eg:
> > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors)
> > Excess errors:
> > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
> > 0.01 ( 50%) 8904 ( 0%)
> > callgraph construction : 0.00 ( 0%) 0.00 ( 0%)
> > 0.01 ( 50%) 4096 ( 0%)
> >
> > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests
> > now use dg-prune-output "k" and dg-prune-output " 0 "
> > which is not enough.
> >
> > Can you fix this?
>
> Sorry for the breakage. I hope Marek has a fix that he'll install.
Should be fixed now!
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 2/3] Use MiB unit when displaying memory allocation.
2020-09-22 13:02 ` Marek Polacek
@ 2020-09-22 13:24 ` Marek Polacek
0 siblings, 0 replies; 16+ messages in thread
From: Marek Polacek @ 2020-09-22 13:24 UTC (permalink / raw)
To: Martin Liška, GCC Patches, Jan Hubicka
On Tue, Sep 22, 2020 at 09:02:08AM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 10:30:00AM +0200, Martin Liška wrote:
> > On 9/22/20 9:47 AM, Christophe Lyon wrote:
> > > On Wed, 2 Sep 2020 at 15:29, Martin Liška <mliska@suse.cz> wrote:
> > > >
> > > > On 9/1/20 4:04 PM, Jan Hubicka wrote:
> > > > > > The patch is about usage of MiB in memory allocation reports.
> > > > > > I see it much better readable than values displayed in KiB:
> > > > > >
> > > > > > Reading object files: tramp3d-v4.o {GC released 1 MiB} {GC 19 MiB -> 19 MiB} {GC 19 MiB} {heap 12 MiB}
> > > > > > Reading the symbol table:
> > > > > > Merging declarations: {GC released 1 MiB madv_dontneed 0 MiB} {GC 27 MiB -> 27 MiB} {GC 27 MiB} {heap 15 MiB}
> > > > > > Reading summaries: <odr> {GC 27 MiB} {heap 15 MiB} <profile_estimate> {GC 27 MiB} {heap 15 MiB} <icf> {GC 27 MiB} {heap 15 MiB} <cp> {GC 27 MiB} {heap 15 MiB} <sra> {GC 27 MiB} {heap 15 MiB} <fnsummary> {GC 30 MiB} {heap 15 MiB} <pure-const> {GC 30 MiB} {heap 15 MiB} {GC 30 MiB}
> > > > > > Merging symbols: {heap 15 MiB}Materializing decls:
> > > > > > <odr> {heap 15 MiB} <whole-program> {heap 15 MiB} <profile_estimate> {heap 15 MiB} <icf> {heap 15 MiB} <devirt> {heap 15 MiB} <cp> {heap 15 MiB} <sra> {heap 15 MiB} <cdtor> {heap 15 MiB} <fnsummary> {heap 15 MiB} <inline> {heap 15 MiB} <pure-const> {heap 15 MiB} <free-fnsummary> {GC released 1 MiB madv_dontneed 2 MiB} {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} <static-var> {heap 15 MiB} <single-use> {heap 15 MiB} <comdats> {heap 15 MiB}
> > > > > > Streaming out {GC trimmed to 27 MiB, 28 MiB mapped} {heap 15 MiB} ./a.ltrans0.o ( 11257 insns) ./a.ltrans1.o ( 11293 insns) ./a.ltrans2.o ( 8669 insns) ./a.ltrans3.o ( 138934 insns)
> > > > >
> > > > > One problem I see here is that while it is OK for Firefox builds it is
> > > > > bit too coarse for smaller testcases where the memory use is still
> > > > > importnat. I guess we may just print KBs before the large gets too
> > > > > large, just like norton commander does? :)
> > > >
> > > > Sure, let's do it using SIZE_AMOUNT macro.
> > > >
> > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > >
> > >
> > > Hi,
> > >
> > > This change is causing gcc.dg/timevar[12].C to fail randomly, eg:
> > > FAIL: g++.dg/ext/timevar1.C -std=gnu++2a (test for excess errors)
> > > Excess errors:
> > > phase opt and generate : 0.00 ( 0%) 0.00 ( 0%)
> > > 0.01 ( 50%) 8904 ( 0%)
> > > callgraph construction : 0.00 ( 0%) 0.00 ( 0%)
> > > 0.01 ( 50%) 4096 ( 0%)
> > >
> > > because SIZE_AMOUNT generates no suffix if the size is < 10k, and those tests
> > > now use dg-prune-output "k" and dg-prune-output " 0 "
> > > which is not enough.
> > >
> > > Can you fix this?
> >
> > Sorry for the breakage. I hope Marek has a fix that he'll install.
>
> Should be fixed now!
Ah, timevar1.C has the same problem. Will fix that one now too.
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-09-22 13:24 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-01 12:31 [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-01 12:32 ` [PATCH 2/3] Use MiB unit when displaying memory allocation Martin Liška
2020-09-01 14:04 ` Jan Hubicka
2020-09-02 13:28 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
2020-09-22 7:47 ` Christophe Lyon
2020-09-22 8:30 ` Martin Liška
2020-09-22 13:02 ` Marek Polacek
2020-09-22 13:24 ` Marek Polacek
2020-09-01 12:33 ` [PATCH 3/3] Use more ONE_? in GGC functions Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-17 21:57 ` Jeff Law
2020-09-01 13:38 ` [PATCH 4/N] Change timevar memory allocation to MiB Martin Liška
2020-09-02 13:29 ` Martin Liška
2020-09-02 13:28 ` [PATCH 1/3] Support new mallinfo2 function Martin Liška
2020-09-17 21:56 ` Jeff Law
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 read-only IMAP folder(s) and NNTP newsgroup(s).