Re: [9fans] mmap - Plan9

This is a discussion on Re: [9fans] mmap - Plan9 ; * erik quanstrom wrote: > > * Roman V. Shaposhnik wrote: > > > On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote: > > > > Convenience is one point (sometimes be a big point), but another > > ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: [9fans] mmap

  1. Re: [9fans] mmap

    * erik quanstrom wrote:
    > > * Roman V. Shaposhnik wrote:
    > > > On Wed, 2008-07-30 at 17:29 +0200, Enrico Weigelt wrote:
    > > > > Convenience is one point (sometimes be a big point), but another
    > > > > important one is sharing. Without mmap(), an (real) shared library
    > > > > support most likely will require special kernel support.
    > > >
    > > > What aspect of shared libraries are you aching for? Dynamic
    > > > linking or the dynamic loading?

    > >
    > > 3rd: Sharing pages.

    >
    > segment(3) already provides this.


    hmm, so segment(3)+segattach(2) can be seen as a kind of a frontend
    for mmap() ;-)

    But now I'm curious how executables and shared libraries are
    actually handled on plan9.


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


  2. Re: [9fans] mmap

    On Sun, Nov 2, 2008 at 8:18 PM, Enrico Weigelt wrote:

    > But now I'm curious how executables and shared libraries are
    > actually handled on plan9.
    >


    what's a shared library?

    Executables:

    /sys/src/9/

    Check it out, it's short and sweet.

    ron


  3. Re: [9fans] mmap

    >> But now I'm curious how executables and shared libraries are
    >> actually handled on plan9.
    >>


    >what's a shared library?


    even if plan 9 were to have them, and i were doing it, i don't think i'd
    implement them using mmap and trampolines.


  4. Re: [9fans] mmap and shared libraries

    A thought ...

    Shared libraries do 2 possibly useful things:
    1) save space
    2) stop you having to re-link when a new library is released.

    Now 2) doesn't really happen anyway, due to .so versioning hell,
    so we're left with 1) ...

    I know it's kind-of hacky and unstructured (how do you know the venti
    block size?),
    but could you not block-align the library members in the .a,
    so venti would do the sharing on disk for you?

    As a further step, you could also page align the text segments of the
    library members,
    then implement a venti-like scheme for read-only pages in memory,
    so that when the executable loads, it gets any common library pages
    shared.

    Dave.

    P.S. Sorry not to make Volos: where are the rest of the photos?


  5. Re: [9fans] mmap and shared libraries

    dave.l@mac.com wrote:
    > A thought ...
    >
    > Shared libraries do 2 possibly useful things:
    > 1) save space
    > 2) stop you having to re-link when a new library is released.
    >
    > Now 2) doesn't really happen anyway, due to .so versioning hell,
    > so we're left with 1) ...
    >
    > I know it's kind-of hacky and unstructured (how do you know the venti
    > block size?),
    > but could you not block-align the library members in the .a,
    > so venti would do the sharing on disk for you?


    Look at this:
    http://gsoc.cat-v.org/people/mjl/blo...n_fingerprints

    > As a further step, you could also page align the text segments of the
    > library members,
    > then implement a venti-like scheme for read-only pages in memory,
    > so that when the executable loads, it gets any common library pages
    > shared.
    >
    > Dave.
    >
    > P.S. Sorry not to make Volos: where are the rest of the photos?
    >




  6. Re: [9fans] mmap and shared libraries

    > A thought ...
    >
    > Shared libraries do 2 possibly useful things:
    > 1) save space
    > 2) stop you having to re-link when a new library is released.
    >
    > Now 2) doesn't really happen anyway, due to .so versioning hell,
    > so we're left with 1) ...


    I can run Plan 9 quite nicely in 128 MB of RAM. In the same amount of
    memory FreeBSD is paging nightmare, despite it's wonderfully complex
    shared library environment. Oh, and Solaris won't even boot with less 512
    MB these days.

    There is no space shortage on Plan 9 that's looking for a solution.


  7. Re: [9fans] mmap and shared libraries

    On Nov 3, 2008, at 5:16 AM, dave.l@mac.com wrote:
    > A thought ...
    >
    > Shared libraries do 2 possibly useful things:
    > 1) save space
    > 2) stop you having to re-link when a new library is released.
    >
    > Now 2) doesn't really happen anyway, due to .so versioning hell,
    > so we're left with 1) ...
    >
    > I know it's kind-of hacky and unstructured (how do you know the
    > venti block size?),
    > but could you not block-align the library members in the .a,
    > so venti would do the sharing on disk for you?
    >
    > As a further step, you could also page align the text segments of
    > the library members,
    > then implement a venti-like scheme for read-only pages in memory,
    > so that when the executable loads, it gets any common library pages
    > shared.


    I was thinking about exactly the same approach when I was
    contemplating the
    evils of dynamic linking. It seems that if you link statically and you
    use FS
    to help you coalesce identical blocks (on storage devices and in RAM)
    you get
    all of the potential benefits of a dynamically linked binary except
    one -- distribution.
    A standalone statically linked binary is going to be considerable
    larger while
    in flight over data links.

    > P.S. Sorry not to make Volos: where are the rest of the photos?


    Yeah -- where are they?!?! ;-)

    Thanks,
    Roman.



  8. Re: [9fans] mmap and shared libraries

    On Tue, Nov 4, 2008 at 9:17 PM, Roman Shaposhnik wrote:

    > A standalone statically linked binary is going to be considerable larger
    > while
    > in flight over data links.
    >


    ah yes well maybe.

    rminnich@login3.surveyor:~/mtelnet> ls -l `which emacs`
    -rwxr-xr-t 1 root root 4587528 2006-06-17 06:59 /usr/bin/emacs
    rminnich@login3.surveyor:~/mtelnet> ls -l `which acme`
    -rwxr-xr-x 1 rminnich users 1361257 2008-11-04 12:39
    /home/rminnich/plan9/bin/acme
    rminnich@login3.surveyor:~/mtelnet>

    I realize that is utterly unfair. Sort of.



    ron


  9. Re: [9fans] mmap and shared libraries

    >> A standalone statically linked binary is going to be considerable larger
    >> while
    >> in flight over data links.


    But that static binary only flies once, geting sucked into memory
    with a (mostly) simple bcopy equiv at process launch time. Shared
    memory regimes thrash the living daylights out of MMUs and PTLBs, on each
    and every context switch.


+ Reply to Thread