[patch] Fix PR 84487, large rodata increase in tonto and other programs

[patch] Fix PR 84487, large rodata increase in tonto and other programs

[Thomas Koenig]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hello world,

the attached patch fixes a 8/9 regression where _def_init, an internal
Fortran variable containing only zeros, was placed into the .rodata
section. This led to a large increase in executable size.

There should be no impact on other languages because the change to
varasm.c is guarded by lang_GNU_Fortran ().

Regarding the test case: I did find one other test which checks
for .bss, so I suppose this is safe.

Regression-tested with a full test (--enable-languages=all and
make -j64 -k check) on POWER9.

I would like to apply it to both affected branches.

OK for the general and the Fortran part?

Regards

	Thomas

2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>

         PR fortran/84487
         * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
         artificial.

2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>

         PR fortran/84487
         * varasm.c (bss_initializer_p): If we are compiling Fortran, the
         decl is artifical and it has a size larger than 255, it can be
         put into BSS.

2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>

         PR fortran/84487
         * gfortran.dg/def_init_1.f90: New test.



[-- Attachment #2: p5.diff --]
[-- Type: text/x-patch, Size: 1523 bytes --]

Index: fortran/trans-decl.c
===================================================================
--- fortran/trans-decl.c	(Revision 270182)
+++ fortran/trans-decl.c	(Arbeitskopie)
@@ -1865,7 +1865,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
 
   if (sym->attr.vtab
       || (sym->name[0] == '_' && gfc_str_startswith (sym->name, "__def_init")))
-    TREE_READONLY (decl) = 1;
+    {
+      TREE_READONLY (decl) = 1;
+      DECL_ARTIFICIAL (decl) = 1;
+    }
 
   return decl;
 }
Index: varasm.c
===================================================================
--- varasm.c	(Revision 270182)
+++ varasm.c	(Arbeitskopie)
@@ -1007,9 +1007,13 @@ decode_reg_name (const char *name)
 bool
 bss_initializer_p (const_tree decl, bool named)
 {
-  /* Do not put non-common constants into the .bss section, they belong in
-     a readonly section, except when NAMED is true.  */
-  return ((!TREE_READONLY (decl) || DECL_COMMON (decl) || named)
+  /* Do not put non-common constants into the .bss section, they
+     belong in a readonly section, except when NAMED is true or when
+     we are dealing with an artificial declaration, in the Fortran
+     compiler only, above a certain size.  */
+  return ((!TREE_READONLY (decl) || DECL_COMMON (decl) || named
+	   || (lang_GNU_Fortran () && DECL_ARTIFICIAL (decl)
+	       && (tree_to_uhwi (DECL_SIZE_UNIT (decl)) > 255 )))
 	  && (DECL_INITIAL (decl) == NULL
 	      /* In LTO we have no errors in program; error_mark_node is used
 	         to mark offlined constructors.  */

[-- Attachment #3: def_init_1.f90 --]
[-- Type: text/x-fortran, Size: 273 bytes --]

! { dg-do compile }
! PR 84487 - check that def_init, if it is large,
! is put into .bss.
module TYPES_MODULE

  implicit none

  type archive_type
     character(2**18) :: root_name
  end type archive_type
end module TYPES_MODULE
! { dg-final { scan-assembler "\.bss" } }

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Paul Richard Thomas]

Hi Thomas,

Thanks for your determination in dealing with this. It has been on my
TODO list for a long time but, like you at the outset, I had no idea
how to deal with it.

OK on the fortran side.

Paul

On Sat, 13 Apr 2019 at 19:48, Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> Hello world,
>
> the attached patch fixes a 8/9 regression where _def_init, an internal
> Fortran variable containing only zeros, was placed into the .rodata
> section. This led to a large increase in executable size.
>
> There should be no impact on other languages because the change to
> varasm.c is guarded by lang_GNU_Fortran ().
>
> Regarding the test case: I did find one other test which checks
> for .bss, so I suppose this is safe.
>
> Regression-tested with a full test (--enable-languages=all and
> make -j64 -k check) on POWER9.
>
> I would like to apply it to both affected branches.
>
> OK for the general and the Fortran part?
>
> Regards
>
>         Thomas
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
>          artificial.
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * varasm.c (bss_initializer_p): If we are compiling Fortran, the
>          decl is artifical and it has a size larger than 255, it can be
>          put into BSS.
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * gfortran.dg/def_init_1.f90: New test.
>
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]

On Sat, Apr 13, 2019 at 8:48 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> Hello world,
>
> the attached patch fixes a 8/9 regression where _def_init, an internal
> Fortran variable containing only zeros, was placed into the .rodata
> section. This led to a large increase in executable size.
>
> There should be no impact on other languages because the change to
> varasm.c is guarded by lang_GNU_Fortran ().
>
> Regarding the test case: I did find one other test which checks
> for .bss, so I suppose this is safe.
>
> Regression-tested with a full test (--enable-languages=all and
> make -j64 -k check) on POWER9.
>
> I would like to apply it to both affected branches.
>
> OK for the general and the Fortran part?

This won't work with LTO.  Note we have the issue in the middle-end as well
since we promote variables we see are not written to to TREE_READONLY.
This can be seen with (the somewhat artificial...):

int a[1024*1024] = { 0 };

int __attribute__((noinline)) foo() { return *(volatile int *)a; }

int main()
{
  return foo ();
}

where without -flto a gets placed into .bss while with -flto it
gets into .rodata.  So I believe we should add a DECL flag
specifying whether for section placement we can "ignore"
TREE_READONLY.  We'd initialize that with the original
state of TREE_READONLY so that the R/O promotion doesn't
change section placement.  Also the Fortran FE can then
simply set this flag on variables that may live in .bss.

There are 14 unused bits in tree_decl_with_vis so a
patch for the middle-end part could look like the attached
(w/o solving the LTO issue yet).

Of course adding sth like a .robss section would be nice.

Richard.

> Regards
>
>         Thomas
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
>          artificial.
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * varasm.c (bss_initializer_p): If we are compiling Fortran, the
>          decl is artifical and it has a size larger than 255, it can be
>          put into BSS.
>
> 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
>
>          PR fortran/84487
>          * gfortran.dg/def_init_1.f90: New test.
>
>

[-- Attachment #2: p --]
[-- Type: application/octet-stream, Size: 2662 bytes --]

Index: gcc/tree-core.h
===================================================================
--- gcc/tree-core.h	(revision 270306)
+++ gcc/tree-core.h	(working copy)
@@ -1763,6 +1763,7 @@ struct GTY(()) tree_decl_with_vis {
  /* Used for FUNCTION_DECL, VAR_DECL and in C++ for TYPE_DECL.  */
  ENUM_BITFIELD(symbol_visibility) visibility : 2;
  unsigned visibility_specified : 1;
+ unsigned declared_nonconst : 1;
 
  /* Belong to FUNCTION_DECL exclusively.  */
  unsigned init_priority_p : 1;
@@ -1776,7 +1777,7 @@ struct GTY(()) tree_decl_with_vis {
  unsigned final : 1;
  /* Belong to FUNCTION_DECL exclusively.  */
  unsigned regdecl_flag : 1;
- /* 14 unused bits. */
+ /* 13 unused bits. */
 };
 
 struct GTY(()) tree_var_decl {
Index: gcc/tree.h
===================================================================
--- gcc/tree.h	(revision 270306)
+++ gcc/tree.h	(working copy)
@@ -802,6 +802,11 @@ extern void omp_clause_range_check_faile
    as "const" function (can only read its arguments).  */
 #define TREE_READONLY(NODE) (NON_TYPE_CHECK (NODE)->base.readonly_flag)
 
+/* In a VAR_DECL, whether the variable was not declared const.  If set
+   then a TREE_READONLY variable may still be put into .bss.  */
+#define VAR_DECLARED_NONCONST(NODE) \
+  (TREE_CHECK (NODE, VAR_DECL)->decl_with_vis.declared_nonconst)
+
 /* Value of expression is constant.  Always on in all ..._CST nodes.  May
    also appear in an expression or decl where the value is constant.  */
 #define TREE_CONSTANT(NODE) (NON_TYPE_CHECK (NODE)->base.constant_flag)
@@ -4893,6 +4898,7 @@ extern bool stdarg_p (const_tree);
 extern bool prototype_p (const_tree);
 extern bool is_typedef_decl (const_tree x);
 extern bool typedef_variant_p (const_tree);
+extern bool auto_var_p (const_tree);
 extern bool auto_var_in_fn_p (const_tree, const_tree);
 extern tree build_low_bits_mask (tree, unsigned);
 extern bool tree_nop_conversion_p (const_tree, const_tree);
Index: gcc/varasm.c
===================================================================
--- gcc/varasm.c	(revision 270306)
+++ gcc/varasm.c	(working copy)
@@ -1009,7 +1009,10 @@ bss_initializer_p (const_tree decl, bool
 {
   /* Do not put non-common constants into the .bss section, they belong in
      a readonly section, except when NAMED is true.  */
-  return ((!TREE_READONLY (decl) || DECL_COMMON (decl) || named)
+  return (((!TREE_READONLY (decl)
+	    || (TREE_CODE (decl) == VAR_DECL && VAR_DECLARED_NONCONST (decl)))
+	   || DECL_COMMON (decl)
+	   || named)
 	  && (DECL_INITIAL (decl) == NULL
 	      /* In LTO we have no errors in program; error_mark_node is used
 	         to mark offlined constructors.  */

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Jan Hubicka]

> 
> This won't work with LTO.  Note we have the issue in the middle-end as well
> since we promote variables we see are not written to to TREE_READONLY.
> This can be seen with (the somewhat artificial...):
> 
> int a[1024*1024] = { 0 };
> 
> int __attribute__((noinline)) foo() { return *(volatile int *)a; }
> 
> int main()
> {
>   return foo ();
> }
> 
> where without -flto a gets placed into .bss while with -flto it
> gets into .rodata.  So I believe we should add a DECL flag
> specifying whether for section placement we can "ignore"
> TREE_READONLY.  We'd initialize that with the original
> state of TREE_READONLY so that the R/O promotion doesn't
> change section placement.  Also the Fortran FE can then
> simply set this flag on variables that may live in .bss.
> 
> There are 14 unused bits in tree_decl_with_vis so a
> patch for the middle-end part could look like the attached
> (w/o solving the LTO issue yet).
> 
> Of course adding sth like a .robss section would be nice.

Yep, but I think what you propose works well in practice (I am not sure
if we are forced to put const delcared variables to readonly memory and
if we can't do this as binary size optimization always). The patch
looks fine to me.  Would be possible to place the flags into
varpool_node rather then TREE? It is a lot easier to manage flags
there.

Honza
> 
> Richard.
> 
> > Regards
> >
> >         Thomas
> >
> > 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
> >
> >          PR fortran/84487
> >          * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
> >          artificial.
> >
> > 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
> >
> >          PR fortran/84487
> >          * varasm.c (bss_initializer_p): If we are compiling Fortran, the
> >          decl is artifical and it has a size larger than 255, it can be
> >          put into BSS.
> >
> > 2019-04-13  Thomas Koenig  <tkoenig@gcc.gnu.org>
> >
> >          PR fortran/84487
> >          * gfortran.dg/def_init_1.f90: New test.
> >
> >

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Florian Weimer]

* Richard Biener:

> Of course adding sth like a .robss section would be nice.

I think this is strictly a link editor issue because a read-only PT_LOAD
directive with a memory size larger than the file size already produces
read-only zero pages, without requiring a file allocation.

Thanks,
Florian

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Segher Boessenkool]

On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> * Richard Biener:
> 
> > Of course adding sth like a .robss section would be nice.
> 
> I think this is strictly a link editor issue because a read-only PT_LOAD
> directive with a memory size larger than the file size already produces
> read-only zero pages, without requiring a file allocation.

But .rodata normally is not the last thing in its segment (the .eh*
things are after it, and those are usually not all zero).


Segher

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Florian Weimer]

* Segher Boessenkool:

> On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
>> * Richard Biener:
>> 
>> > Of course adding sth like a .robss section would be nice.
>> 
>> I think this is strictly a link editor issue because a read-only PT_LOAD
>> directive with a memory size larger than the file size already produces
>> read-only zero pages, without requiring a file allocation.
>
> But .rodata normally is not the last thing in its segment (the .eh*
> things are after it, and those are usually not all zero).

If you don't mind the proliferation of load segments (we've add many of
them in recent years), placement does not matter.

Thanks,
Florian

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Richard Biener]

On Tue, Apr 16, 2019 at 11:33 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Segher Boessenkool:
>
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >>
> >> > Of course adding sth like a .robss section would be nice.
> >>
> >> I think this is strictly a link editor issue because a read-only PT_LOAD
> >> directive with a memory size larger than the file size already produces
> >> read-only zero pages, without requiring a file allocation.
> >
> > But .rodata normally is not the last thing in its segment (the .eh*
> > things are after it, and those are usually not all zero).
>
> If you don't mind the proliferation of load segments (we've add many of
> them in recent years), placement does not matter.

Btw, besides being a link editor issue the issue also shows in object
file size.  Not sure if a similar trick exists for those (.rodata with NOBITS?)

Richard.

> Thanks,
> Florian

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Segher Boessenkool]

On Tue, Apr 16, 2019 at 12:05:56PM +0200, Richard Biener wrote:
> On Tue, Apr 16, 2019 at 11:33 AM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Segher Boessenkool:
> >
> > > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> > >> * Richard Biener:
> > >>
> > >> > Of course adding sth like a .robss section would be nice.
> > >>
> > >> I think this is strictly a link editor issue because a read-only PT_LOAD
> > >> directive with a memory size larger than the file size already produces
> > >> read-only zero pages, without requiring a file allocation.
> > >
> > > But .rodata normally is not the last thing in its segment (the .eh*
> > > things are after it, and those are usually not all zero).
> >
> > If you don't mind the proliferation of load segments (we've add many of
> > them in recent years), placement does not matter.
> 
> Btw, besides being a link editor issue the issue also shows in object
> file size.  Not sure if a similar trick exists for those (.rodata with NOBITS?)

Section type SHT_NOBITS does the trick, yes.


Segher

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Segher Boessenkool]

On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
> 
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >> 
> >> > Of course adding sth like a .robss section would be nice.
> >> 
> >> I think this is strictly a link editor issue because a read-only PT_LOAD
> >> directive with a memory size larger than the file size already produces
> >> read-only zero pages, without requiring a file allocation.
> >
> > But .rodata normally is not the last thing in its segment (the .eh*
> > things are after it, and those are usually not all zero).
> 
> If you don't mind the proliferation of load segments (we've add many of
> them in recent years), placement does not matter.

Many (or at least some) ABIs have requirements wrt placement, and number
and kind of segments even.

Is there any disadvantage to having a .robss section (that is mapped at the
end of the text segment, or some other r/o segment, so that its data does
not have to exist in object and executable files)?


Segher

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Jakub Jelinek]

On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
> 
> > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> >> * Richard Biener:
> >> 
> >> > Of course adding sth like a .robss section would be nice.
> >> 
> >> I think this is strictly a link editor issue because a read-only PT_LOAD
> >> directive with a memory size larger than the file size already produces
> >> read-only zero pages, without requiring a file allocation.
> >
> > But .rodata normally is not the last thing in its segment (the .eh*
> > things are after it, and those are usually not all zero).
> 
> If you don't mind the proliferation of load segments (we've add many of
> them in recent years), placement does not matter.

That is something I really dislike, each load segment has a significant cost
and from what I remember, at least one of the 4 PT_LOADs in current setup is
completely useless:
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x02bf60 0x02bf60 R   0x1000
  LOAD           0x02c000 0x000000000002c000 0x000000000002c000 0x0a74a5 0x0a74a5 R E 0x1000
  LOAD           0x0d4000 0x00000000000d4000 0x00000000000d4000 0x033fd0 0x033fd0 R   0x1000
  LOAD           0x108d50 0x0000000000109d50 0x0000000000109d50 0x00b814 0x0153d8 RW  0x1000
there is no reason not to reorder at least on most targets the sections such
that there is just one R, one R E and one RW segment.

	Jakub

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Segher Boessenkool]

On Tue, Apr 16, 2019 at 12:16:16PM +0200, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 11:33:39AM +0200, Florian Weimer wrote:
> > * Segher Boessenkool:
> > 
> > > On Mon, Apr 15, 2019 at 01:54:11PM +0200, Florian Weimer wrote:
> > >> * Richard Biener:
> > >> 
> > >> > Of course adding sth like a .robss section would be nice.
> > >> 
> > >> I think this is strictly a link editor issue because a read-only PT_LOAD
> > >> directive with a memory size larger than the file size already produces
> > >> read-only zero pages, without requiring a file allocation.
> > >
> > > But .rodata normally is not the last thing in its segment (the .eh*
> > > things are after it, and those are usually not all zero).
> > 
> > If you don't mind the proliferation of load segments (we've add many of
> > them in recent years), placement does not matter.
> 
> That is something I really dislike, each load segment has a significant cost
> and from what I remember, at least one of the 4 PT_LOADs in current setup is
> completely useless:
>   LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x02bf60 0x02bf60 R   0x1000
>   LOAD           0x02c000 0x000000000002c000 0x000000000002c000 0x0a74a5 0x0a74a5 R E 0x1000
>   LOAD           0x0d4000 0x00000000000d4000 0x00000000000d4000 0x033fd0 0x033fd0 R   0x1000
>   LOAD           0x108d50 0x0000000000109d50 0x0000000000109d50 0x00b814 0x0153d8 RW  0x1000
> there is no reason not to reorder at least on most targets the sections such
> that there is just one R, one R E and one RW segment.

It is more painful if your segments are aligned to 64kB or anything else
bigger, too.


Segher

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Thomas König]

Hi,

thanks a lot for the extensive discussion :-)

How should we now proceed, first for gcc 9, snd then for backporting?
Use Richard‘s patch with the corresponding Fortran FE change?

Regards

Thomas

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Richard Biener]

On Wed, Apr 17, 2019 at 9:19 AM Thomas König <tk@tkoenig.net> wrote:
>
> Hi,
>
> thanks a lot for the extensive discussion :-)
>
> How should we now proceed, first for gcc 9, snd then for backporting?
> Use Richard‘s patch with the corresponding Fortran FE change?

Btw, for the testcase the fortran FE could also simply opt to not
make def_init TREE_READONLY.  Or even better, for all-zero
initialization omit the explicit initialization data and instead
mark it specially in the vtable (just use a NULL initializer
denoting zero-initialization?).  Even .bss costs (runtime) memory.

But yes, my patch would be a way to solve the middle-end issue
of promoting a variable TREE_READONLY, preventing .bss use.
And the FE could then "abuse" this feature.  Note the middle-end
already special-cases variables with an explicit section so the
Fortran FE can already use that feature to put the initializer into
.bss explicitely (set_decl_section_name (decl, ".bss"),
conditional on availability (not 100% sure how to test that...).
Your testcase probably will fail on targets w/o .bss section support.

Richard.

> Regards
>
> Thomas

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Florian Weimer]

* Richard Biener:

> On Wed, Apr 17, 2019 at 9:19 AM Thomas König <tk@tkoenig.net> wrote:
>>
>> Hi,
>>
>> thanks a lot for the extensive discussion :-)
>>
>> How should we now proceed, first for gcc 9, snd then for backporting?
>> Use Richard‘s patch with the corresponding Fortran FE change?
>
> Btw, for the testcase the fortran FE could also simply opt to not
> make def_init TREE_READONLY.  Or even better, for all-zero
> initialization omit the explicit initialization data and instead
> mark it specially in the vtable (just use a NULL initializer
> denoting zero-initialization?).  Even .bss costs (runtime) memory.

Not just that, .bss adds to the commit charge, while .rodata would not.
So it's not clear that using .bss for zero constants is always a win.

Thanks,
Florian

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Andreas Schwab]

On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:

> Not just that, .bss adds to the commit charge,

Only one page at most.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Florian Weimer]

* Andreas Schwab:

> On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Not just that, .bss adds to the commit charge,
>
> Only one page at most.

That would be a bug.  All of it is anonymous memory which needs backing
from RAM or swap, in case the process writes to it.

Thanks,
Florian

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Andreas Schwab]

On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:

> * Andreas Schwab:
>
>> On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> Not just that, .bss adds to the commit charge,
>>
>> Only one page at most.
>
> That would be a bug.

You cannot avoid it for the page shared with .data, unless you force
.bss to be page aligned.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [patch] Fix PR 84487, large rodata increase in tonto and other programs

[Florian Weimer]

* Andreas Schwab:

> On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Andreas Schwab:
>>
>>> On Apr 17 2019, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> Not just that, .bss adds to the commit charge,
>>>
>>> Only one page at most.
>>
>> That would be a bug.
>
> You cannot avoid it for the page shared with .data, unless you force
> .bss to be page aligned.

Would you please elaborate?

With “commit charge”, I mean address space accounted towards the commit
limit, when Linux is running in vm.overcommit_memory=2 mode.

Thanks,
Florian