Last data page not being filled

Last data page not being filled

[D. J. Bernstein]

When a program has (to take a real example) 220 bytes of initialized
data and 444 bytes of zero-filled data, gcc puts the 220 bytes into the
data segment and the 444 bytes into the bss segment, frittering away a
page of memory per process. It should instead put all 664 bytes into the
data segment.

The general rule is simple: as long as there's something in bss that
fits into the last page of data, move it to the last page of data and
repeat, unless -fminimize-data is specified.

(The reason I care about a page per process is that I'm building systems
on the scale of ten thousand processes. Each process has its own uid,
and memory protection is crucial, so please don't suggest threads.)

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Re: Last data page not being filled

[Alexandre Oliva]

On Jun 27, 2003, "D. J. Bernstein" <djb@cr.yp.to> wrote:

> gcc puts the 220 bytes into the data segment and the 444 bytes into
> the bss segment

GCC puts them in sections, not segments.  It's the linker that maps
sections to segments.  Assuming you're using the GNU linker, the
mailing list in which to discuss such issues is
binutils@sources.redhat.com.  Make sure you have a look at the
documentation of linker scripts in the GNU ld manual first, maybe this
will already solve the problem.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Last data page not being filled

[D. J. Bernstein]

Alexandre Oliva writes:
> Assuming you're using the GNU linker, the mailing list in which to
> discuss such issues is binutils@sources.redhat.com.

Thanks. Sorry for the misdirected message.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

Re: Last data page not being filled

[Zack Weinberg]

"D. J. Bernstein" <djb@cr.yp.to> writes:

> When a program has (to take a real example) 220 bytes of initialized
> data and 444 bytes of zero-filled data, gcc puts the 220 bytes into the
> data segment and the 444 bytes into the bss segment, frittering away a
> page of memory per process. It should instead put all 664 bytes into the
> data segment.

What you really want, I think, is for the linker to recognize that
there is no need to align the breakpoint between data and bss to a
page boundary.  The kernel will zero-fill the last page of the data
segment when it's mapped in, so bss symbols can be stuck into that
space.  Since there is no cost whatsoever to this approach (unlike
your original suggestion which would enlarge executables on disk)
there is no reason not to do it unconditionally.

This probably requires changes both to the linker (part of binutils)
and the dynamic loader (part of glibc, for Linux; normally maintained
with the C library of other systems as well).  

zw

Re: Last data page not being filled

[Richard Henderson]

On Fri, Jun 27, 2003 at 09:45:30AM -0700, Zack Weinberg wrote:
> What you really want, I think, is for the linker to recognize that
> there is no need to align the breakpoint between data and bss to a
> page boundary.

And it doesn't, so I'm not sure where he got this idea.


r~