Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!munnari.oz.au!metro!ipso!runxtsa!brucee
From: brucee@runxtsa.runx.oz.au (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: A shared text (re)implementation
Message-ID: <2070@runxtsa.runx.oz.au>
Date: 28 Jul 90 19:22:09 GMT
References: <19490@orstcs.CS.ORST.EDU>
Distribution: comp.os.minix
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 47

In article <19490@orstcs.CS.ORST.EDU> go@jacobs.CS.ORST.EDU (Gary Oliver) writes:
>This package contains a shared text implementation for minix 1.5.10.
>This code was written about a year ago when all I was running was 1.3
>on an old XT.  I have upgraded to 1.5.10 and an AT and reimplemented
>the patches.  Let me know if you have any problems.

I have been working on another version of shared text. Most of it was
written by Peter Housel before he went on holidays. It is basically the
same as Gary's version except it attempts to implement `sticky' text
(where memory allocated for program text is kept around for a while
after all copies of a program exit, to be used with a later copy). This
still has fragmentation problems like those described by Gary.

For me, the time savings from sticky shared text are more important than
the space savings:

386 kernel make with Housel/Evans' (sticky) shared text:
    1:11.00 real      44.13 user      11.15 sys (300K cache)
    2:39.00 real      44.36 user      15.46 sys  (50K cache)

386 kernel make with Oliver's shared text:
    1:54.00 real      44.25 user      16.10 sys (300K cache)
    3:13.00 real      43.90 user      20.86 sys  (50K cache)

386 kernel make with no shared text (actually Housel/Evans' disabled)
    1:53.00 real      44.33 user      15.36 sys (300K cache)
    3:14.00 real      44.00 user      21.65 sys  (50K cache)

The differences are probably due to both caches being too small, so without
sticky text, the compiler passes get reloaded from the disk unnecessarily,
and/or they clog up the cache and waste space that would be better given to
i/o files.

These times are with a kernel change that improves both the real and system
times of the fastest case by 3 or 4 sec, and another change to count the
system time better, so the system time reported is increased by 2 or 3 sec.

Both implementations are limited to sharing separate I&D executables, so
they are of no use on the ST or with Minix-386 executables produced by gcc.
I have started to work on that. Another possibilty is to copy memory around
to completely eliminate memory fragmentation on Minix-PC (safely in protected
mode, not quite safely in real mode). This should be worth 50K, and sharing
shells should be worth 50K, so 640K memory might even be usable :-).
-- 
Bruce Evans
Internet: brucee@runxtsa.runx.oz.au    UUCP: uunet!runxtsa.runx.oz.au!brucee
(My other address (evans@ditsyda.oz.au) no longer works)