[9fans] automatic page sharing

[9fans] automatic page sharing

[Enrico Weigelt]

Hi folks,


some time ago, we had several discussions about shared libraries,
mmap(), etc. One of the major arguments for shared libraries is
to share code pages between processes - and the traditional *nix
approach to do so is mmap() (at least on the systems I know).

Assuming statically linked-in libraries are properly aligned,
we'll have lots of equal pages in the system, so the kernel could
find and automatically map them together.

What do you think about this approach ?
Would it be hard to implement this ?


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] automatic page sharing

[tlaronde]

On Sat, Apr 18, 2009 at 07:05:07PM +0200, Enrico Weigelt wrote:
>
> Assuming statically linked-in libraries are properly aligned,
> we'll have lots of equal pages in the system, so the kernel could
> find and automatically map them together.
>

Well that's one of the 3 classical options:

1) static linking.

2) static shared libraries [your proposal]

3) dynamically linked shared libraries.

For what is worth, you can find explanations in "Linkers and Loaders" by
John R. Levine, Morgan Kaufmann, ISBN 1-55860-496-0.

HTH,
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] automatic page sharing

[Russ Cox]

> Assuming statically linked-in libraries are properly aligned,
> we'll have lots of equal pages in the system, so the kernel could
> find and automatically map them together.

This is not true.  When static libraries are linked into
a target binary, only the necessary objects are taken,
and all the symbol references are resolved (avoiding
the need for relocation at load time), and the code is
not position-independent.  So even if they were "properly
aligned", the bits of common code would be very small.

You'll see this if you run an experiment and compare
two big binaries for common code sequences.  They'll
be there, but nothing nearly as big as a page.

Russ

Re: [9fans] automatic page sharing

[Enrico Weigelt]

Russ Cox wrote:

Hi,

>> Assuming statically linked-in libraries are properly aligned,
>> we'll have lots of equal pages in the system, so the kernel could
>> find and automatically map them together.
>
> This is not true.  When static libraries are linked into
> a target binary, only the necessary objects are taken,
> and all the symbol references are resolved (avoiding
> the need for relocation at load time), and the code is
> not position-independent.  So even if they were "properly
> aligned", the bits of common code would be very small.

Assuming PIC, of course ;-)

My idea is to get rid of mmap() for shared libraries but w/o
loosing the code sharing behind the scenes.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] automatic page sharing

[Ethan Grammatikidis]

On Thu, 29 Oct 2009 21:25:59 +0100
Enrico Weigelt <weigelt@metux.de> wrote:

> Russ Cox wrote:
>
> Hi,
>
> >> Assuming statically linked-in libraries are properly aligned,
> >> we'll have lots of equal pages in the system, so the kernel could
> >> find and automatically map them together.
> >
> > This is not true.  When static libraries are linked into
> > a target binary, only the necessary objects are taken,
> > and all the symbol references are resolved (avoiding
> > the need for relocation at load time), and the code is
> > not position-independent.  So even if they were "properly
> > aligned", the bits of common code would be very small.
>
> Assuming PIC, of course ;-)
>
> My idea is to get rid of mmap() for shared libraries but w/o
> loosing the code sharing behind the scenes.

Pardon if this has come up before, but what about the greatly
increased time taken to launch a shared-lib program?  That's quite
unsuitable for the typical unix commands intended to be used
repeatedly, and produces unacceptable load times for apps depending on
many libraries.  I remember Gnome and KDE just before pre-linking was
introduced, they weren't fun.  Are you planning to incorporate
pre-linking or something like it to offset this disadvantage?

Shared libs are like object-oriented programming languages: they allow
you to introduce much greater complexity to a single program but bring
disadvantages too.  There are other ways to deal with the problem such
as (on Plan 9) breaking up the program into servers or commands +
front end, a solution which may also greatly increase the flexibility
of the application.


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] automatic page sharing

[Gorka Guardiola]

On Fri, Oct 30, 2009 at 12:25 AM, Ethan Grammatikidis
<eekee57@fastmail.fm> wrote:
> On Thu, 29 Oct 2009 21:25:59 +0100
> Enrico Weigelt <weigelt@metux.de> wrote:

> Pardon if this has come up before, but what about the greatly
> increased time taken to launch a shared-lib program?  That's quite

Not that much if your loaded caches the binaries of the programs (as
we do) and they
are small and for really shared state you have filesystems which
stay running.

-- 
- curiosity sKilled the cat

Re: [9fans] automatic page sharing

[erik quanstrom]

> > Pardon if this has come up before, but what about the greatly
> > increased time taken to launch a shared-lib program?  That's quite
>
> Not that much if your loaded caches the binaries of the programs (as
> we do) and they
> are small and for really shared state you have filesystems which
> stay running.

i don't think we have shared libraries.

the executable cache would likely interact
badly with shared libraries.

- erik

Re: [9fans] automatic page sharing

[Richard Miller]

> #include <u.h>
> #include<libc.h>
> int main(void){exits(nil);}
>
> is 3317 bytes on my atom box.

Bloatware!  A quick visit to 6th edition Unix (on 32-bit Interdata)
via the SIMH time machine produces this:

# cat >t.c
int main() {exit(0);}
# cc t.c
# ls -l a.out
-rwxrwxrwx  1 root      164 Jun  4 15:53 a.out
# date
Mon Jun  4 15:53:30 EST 1979

To put this into context:

# ls -l /bin/exit /bin/cat /bin/sh
-rwxr-xr-x  1 root     1436 Nov 13  1978 /bin/cat
-rwxr-xr-x  1 root      192 Nov 13  1978 /bin/exit
-rwxr-xr-x  1 root     8316 Nov 13  1978 /bin/sh

Re: [9fans] automatic page sharing

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> contrast /386/bin/sleep, a non-trivial
> executable, at 4422 bytes on my system — 100x smaller.

#include <u.h>
#include<libc.h>
int main(void){exits(nil);}

is 3317 bytes on my atom box.

Re: [9fans] automatic page sharing

[erik quanstrom]

insightful post

> Pardon if this has come up before, but what about the greatly
> increased time taken to launch a shared-lib program?  That's quite

i just built a trivial executable on linux x86-64 with a
main that calls exit(0) as its only action.  the
executable is 722905 bytes (which is larget than any
plan 9 executables, save refugees spin an gs).  so
one can see how too much code can beget unattractive
work arounds.  contrast /386/bin/sleep, a non-trivial
executable, at 4422 bytes on my system — 100x smaller.

- erik