public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Last data page not being filled
       [not found] <20030627070845.6759.qmail@cr.yp.to>
@ 2003-06-27 11:26 ` D. J. Bernstein
  2003-06-27 13:11   ` DJ Delorie
                     ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: D. J. Bernstein @ 2003-06-27 11:26 UTC (permalink / raw)
  To: binutils

When a program has (to take a real example) 220 bytes of initialized
data and 444 bytes of zero-filled data, the GNU tools put the 220 bytes
into the data segment and the 444 bytes into the bss segment, frittering
away a page of memory per process. They 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 the user explicitly asks for different behavior.

(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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Last data page not being filled
  2003-06-27 11:26 ` Last data page not being filled D. J. Bernstein
@ 2003-06-27 13:11   ` DJ Delorie
  2003-06-27 13:51   ` Ian Lance Taylor
  2003-06-27 20:27   ` D. J. Bernstein
  2 siblings, 0 replies; 4+ messages in thread
From: DJ Delorie @ 2003-06-27 13:11 UTC (permalink / raw)
  To: djb; +Cc: binutils


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

Doesn't it already do that?  The bss section should be right after the
data section, so they should share the last page.

Of course, you failed to tell us which target you're using, so maybe
your specific target is asking binutils to do otherwise.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Last data page not being filled
  2003-06-27 11:26 ` Last data page not being filled D. J. Bernstein
  2003-06-27 13:11   ` DJ Delorie
@ 2003-06-27 13:51   ` Ian Lance Taylor
  2003-06-27 20:27   ` D. J. Bernstein
  2 siblings, 0 replies; 4+ messages in thread
From: Ian Lance Taylor @ 2003-06-27 13:51 UTC (permalink / raw)
  To: D. J. Bernstein; +Cc: binutils

"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, the GNU tools put the 220 bytes
> into the data segment and the 444 bytes into the bss segment, frittering
> away a page of memory per process. They should instead put all 664 bytes
> into the data segment.

GNU ld is supposed to already work as you describe.  I just verified
that on i386 GNU/Linux it appears to work.

What is the target?  Can you provide a simple test case?

Ian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Last data page not being filled
  2003-06-27 11:26 ` Last data page not being filled D. J. Bernstein
  2003-06-27 13:11   ` DJ Delorie
  2003-06-27 13:51   ` Ian Lance Taylor
@ 2003-06-27 20:27   ` D. J. Bernstein
  2 siblings, 0 replies; 4+ messages in thread
From: D. J. Bernstein @ 2003-06-27 20:27 UTC (permalink / raw)
  To: binutils

My apologies; I was misled by a few people on the freebsd-performance
mailing list. Now that I investigate more carefully, I see that the GNU
tools do the right thing, keeping bss adjacent to data in the same VM
segment. Please ignore my initial report.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-06-27 20:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20030627070845.6759.qmail@cr.yp.to>
2003-06-27 11:26 ` Last data page not being filled D. J. Bernstein
2003-06-27 13:11   ` DJ Delorie
2003-06-27 13:51   ` Ian Lance Taylor
2003-06-27 20:27   ` D. J. Bernstein

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).