Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!stc!idec!marlow!fox
From: fox@marlow.uucp (Paul Fox)
Newsgroups: comp.unix.microport
Subject: V.3 + top
Message-ID: <468@alice.marlow.uucp>
Date: 12 Oct 88 22:30:27 GMT
Organization: Reuters Ltd PLC, Marlow, England
Lines: 60

Well, I've finally done it. I've finally worked out how to relate
the 'proc' structure to the 'user' structure. I've been needing
this in order to modify the top program to work under V.3.

Boy was that a difficult job - over 8 solid hours looking at the
kernel with 'crash' and the proc.h & user.h include files !!

Now I've done it, I think I can now begin to understand why
V.3 systems are soooo much slowwwer than Xenix systems..

Just to let you know why I think this is so...
We have Uport & ISC V.3 systems running on 4MB 16&20MHz 386's. We
also have a 16MHz Xenix system with 2MB of memory. The Xenix system
beats the pants off of our 20MHz 386's. I've always want ed to
know why. I always presumed this was due to the quality of the
compiler (MSC 5) and the mods which SCO & Msoft have done to the kernel.

Well, I believe differently now.

Xenix uses the old Berkely way of doing memory allocation. Specifically
a fixed 'u' area in which the user area of the currently running process
gets mapped. In order to write a 'ps' type of program you
would look at the proc->p_addr field to determine where in physical
memory the 'u' area of a process would reside. If one of the flags
said it was swapped out, then the p_addr field points to the
address of the 'u' area on /dev/swap.

After hours of trying to understand region tables and page directory 
tables on the 386, I have it sussed.

On V.3, the proc->p_ubptbl points to two page table entries which
between them map the top half and bottom half of the
'u' area. (Two are needed since the u area is > 4K, and < 8K).
The first 4K can be ignored since that maps onto the
kernel stack.

OK, so in my system I have a proc limit of 100 processes. It seems
to me that the u area for these 100 procs pretty much resides in
physical memory all the time. Net result: 100 * 8K taken up in
'u' areas. Thats 800K. Add this to the 500K disk buffers + 1MB for
the kernel. We end up with 2.3MB used up. That leaves me with 1.7MB
for my processes before we subtract the other bits needed by my kernel.

On our Xenix system with 2MB, we have about 1.3MB free for processes.
So as you see the 1.3MB figure and 1.7MB figure are pretty close.

Add to this the mods MS & SCO have done to Xenix to speed it
up and the presumably smaller 'u' areas, then its not
surprising that Xenix wizzes by.

Any comments anyone ? 


=====================
     //        o      All opinions are my own.
   (O)        ( )     The powers that be ...
  /    \_____( )
 o  \         |
    /\____\__/        Tel: +44 628 891313 x. 212
  _/_/   _/_/         UUCP:     fox@marlow.uucp