XBR4DA68%DDATHD21.BITNET@cunyvm.cuny.edu (11/11/90)
In reply to the mail from Fred van Kempen from Nov. 7th, 1990.
I have tried to contact Fred directly, but all mail pathes
seem to be brocken.
Original message :
==============================================================================
Dear Fred,
I will send you this messages on two different pathes,
I hope one works. Please reply during the next two days,
otherwise I would have to send this mail to the
MINIX discussion list.
We have serious problems to reach addresses outside BITNET,
so I ask you, if a message of mine gets scrambled, please
return it with an aprobriate message both to
DA68@DDATHD21.BITNET and POSTMASTER@DDATHD21.BITNET.
We are porting MINIX 1.5.* as a hosted operating system
on top of pSOS+(m) by Software Components Group. This gives
us beside other valuable things a proven kernel debugger.
( boot proms are up and running, just waiting for down -
load of the first version ... )
We would like to have virtual memory. This would save memory
itself by text sharing. It would ease the problems of lacking
reentrancy of most of the common and bought libraries.
For data and stack area, we would like to implement a
"copy on write back" strategy.
Ingo Cyliax has already done invaluable work for us,
he gave us some kBytes of source text well suited for
our hardware to implement sharing and copy on write back.
The next step was to think - why not implement demand paging for
MINIX? ( Ingo Cyliax expressed our view of things best,
we have had discussions before with him.)
Before starting the real implementation, I have listened to
the net and, you talked about some one at Free University in
Amsterdam having already implemented a swapper. I wanted to get
in touch with him to share experience.
We should discuss the problem on a wider base, we must
develop and establish the interfaces, both between software
entities (FS, MM , kernel and swapper) and to the hardware.
Our platform would be all Motorola processors with
a segmented or a paged MMU, others would use iapx286,
-386, -486.
AST does not seems to object this ( our) approach, does he?
We will have to chose allocation algorithms.
Should we take first fit, best fit or buddy buffers ?
Will we use a global or local replacing policy ?
(Or should we do something plain different?)
I for myself think:
1) Though modern mikros are fast, modern disc sub systems have
kept slow. On average it takes only twice the time to read
a whole track as to read one sector. That means, transferring
17 fold to 36 fold of information takes only twice the time.
On one of our SCSI controllers (MVME319), transferring
128 sectors takes only twice as long as transferring one.
2) Modern mikros have only a very limited translation cache.
That means to make address translation efficient, you must
keep translation tables short and chunks of memory to be accessed
rather large to ensure a high hit rate in the translation look
aside cache.
3) For mikros using translation trees, from (2) follows,
that their branches must be kept as short as possible.
Given (1), (2) and (3) one might prefer the buddy buffers like
in Knuth, The Art of Programming, Fundamental Algorithms,
443, or more advanced one.
Thats all I have to talk about, greetings
Adams
PS: If you think, parts of this letter might be of general
interest, you are allowed to send this letter to the discussion list,
after brushing up my English ( and writing style ).