Re: profiling connection overhead

Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sat, Nov 27, 2010 at 11:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> Not sure that information moves us forward. If the postmaster cleared
> >> the memory, we would have COW in the child and probably be even slower.
> 
> > Well, we can determine the answers to these questions empirically.
> 
> Not really.  Per Bruce's description, a page would become COW the moment
> the postmaster touched (either write or read) any variable on it.  Since
> we have no control over how the loader lays out static variables, the
> actual behavior of a particular build would be pretty random and subject
> to unexpected changes caused by seemingly unrelated edits.

I believe all linkers will put initialized data ("data" segment) before
unitialized data ("bss" segment):

	http://en.wikipedia.org/wiki/Data_segment

The only question is whether the linker has data and bss sharing the
same VM page (4k), or whether a new VM page is used when starting the
bss segment.

> Also, the referenced URL only purports to describe the behavior of
> HPUX, which is not exactly a mainstream OS.  I think it requires a
> considerable leap of faith to assume that all or even most platforms
> work the way this suggests, and not in the dumber fashion Andres
> suggested.  Has anybody here actually looked at the relevant Linux
> or BSD kernel code?

I have years ago, but not recently.  You can see the sections on Linux
via objdump:

	$ objdump --headers /bin/ls
	
	/bin/ls:     file format elf32-i386
	
	Sections:
	Idx Name          Size      VMA       LMA       File off  Algn
	...
	 24 .data         0000012c  080611a0  080611a0  000191a0  2**5
	                  CONTENTS, ALLOC, LOAD, DATA
	 25 .bss          00000c40  080612e0  080612e0  000192cc  2**5
	                  ALLOC

Based on this output, a new 4k page is not started for the 'bss'
segment.  It basically uses 32-byte alignment.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +