Path: utzoo!utgpu!watmath!uunet!lll-winken!pacbell!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: unix-pc.general
Subject: Re: Performance questions
Keywords: performance sticky kernel tuning
Message-ID: <1345@mtunb.ATT.COM>
Date: 23 Dec 88 00:04:05 GMT
References: <19@dons3b1.UUCP> <449@uncle.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 108

In article <449@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes:
>In article <19@dons3b1.UUCP> don@dons3b1.UUCP (Don Joslyn) writes:
>...
>>	1.	Can the sticky bit be used to make loading programs faster on
>>		the UNIX-PC?  If yes, what programs have you set the sticky bit
>>		on?  Any comments?
>If you have LOTS of memory, and low system usage, yes.

Please enlighten me: "LOTS of memory"... usually refers to RAM.
But... to my recollection, the cost of the Sticky bit is a few dozen
bytes -- specifically, ONE text-table entry.

OK: in the larger sense DISK SPACE is called "extended memory", "secondary
memory", or other such goodies.  Punch cards might also be.

In MY phantasy, the Sticky bit just locks a shared-TEXT image onto the
swapping disk.  Ergo, you will run out of SWAP SPACE if you're overly
sticky or under-equipped.

(Of course, our beloved operating system, unable to allocate SWAP SPACE,
during an EXEC [or fork?] responds with "ENOMEM"... but it probably does
that if you run out of punch cards, too... ;^)

"Low system usage?"  Mine remains at desk height because of nose-bleeds.
Again: if you're tying up the SWAP with Sticky Bits, it ain't there for
other use.  Running LOTS of programs (pardon the hi-tech talk) may
run ya out of swap space.  So can ONE program if you're into Grand-MALLOC
seizures and bit-graphix.  

My VI starts in 3 seconds, thus staying within the speed limits and
satisfying my primal urges.  It WILL start in ~1 second if I pour
honey over it.  ...@ a cost of 100KB of swap.  Few programs have as
bulky a TEXT portion and few therefore benefit this greatly.

(NB: ONLY TEXT can be locked on SWAP by Stickiness, DATA must be demand
paged.)

Those who benefit MOST are those with the slowest disks -- who are
usually those with the smallest disks and least SWAP space.

__________ <- The bottom line: BATHE OFTEN... and don't get any stickier
than you MUST.

>>	2.	I have 2 meg of memory.  What can I change in /etc/master to
>>		increase disk performance?  How did it help your system
>>		performance?
>You can anything you want in /etc/master, and it will NOT increase you disk
>performance. This weirdo UNIX AT&T put on this machine is not supplied with
>the normal .o files and libraries to re-link the kernel to re-configure it.
>The re-configuration is limited to the parameters that can be poked at with the
>ktune(7) command. All you can change is: nbuf, ninode, nfile, nproc, ntext,
>nclist, npbuf, ncall and nttyhog. It does this by patching a ktune struct in
>the kernel. The kernel uses these values as the "desired" value the next time
>it boots.

This "weirdo" system was spec'd to run with only .5 MB RAM and a 10 MB
disk.  (NO-- it wasn't the greatest COMPILATION-Machine with this
hardware ;-( ) You DON'T put .o's on a system with a 10 MB disk.
CORRECTION: I DON'T, perhaps others do.  Was it a bad original decision?
Do companies ever mis-estimate markets ;^?

OK, ya wanna improve DISK performance?  Clearly you can
    1) try to reduce DISK ACCESSES
        a) By increasing NBUF from 100 to around 120.  
            I doubt it's worth it, as it may increase PAGING.
        b) By decreasing PAGING by adding RAM (or decreasing
	   page-contention -- ie., decreasing Program size,
	    skipping UA, or maybe DECREASING NBUF!)
            Rough recollections: a BASIC 1 MB system is already
            "consuming" ~1.2 MB RAM by the time UA has spawned a
	    single KSH.  About 500KB of this is PAGED-OUT -- but
	    some will flush through with each window change, "smgr"
	    update, or background/daemon activity.  The kernel will
	    attempt to keep 200KB available/free/un-attached -- to
	    permit reasonably fast forks & exec's.  The system will
	    become claustrophobic with less than 64KB free space.
	    _________ <- Re-lining your bottom: if, with 2 MB RAM,
	    you have tasks ACTIVELY accessing more than (around)
	    1.2MB "at once", you're a candidate for more RAM.
	    (Or if you have tasks locking up great-green-gobs of
	    SHARED-MEMORY, which is LOCKED IN RAM.)
		CAVEAT: The above paragraph is backed by my
		hallucinations, not by a specific study of the
		issue.
    2) get a faster disk.
The "1b)" wins if you're thrashing and "2)" wins if you've a slow disk.

>>	3.	Should I add -s to the fsck command in /etc/rc to sort the free
>>		list?  If yes, why should I?
>This one is very clumsy on a one drive, one partition machine, but it could
>be done easily at boot-up time in /etc/rc.

I do it on most of the machine's I control, but I'm a noted masochist
(or I wouldn't be writing this ;<)  It IS easier on multi-partition
systems and on a full stomach.

You are making a REASONABLE inquiry whose answer chains through
many more concepts than I care to stumble through.  Regular FSCK-ing
is but ONE in a number of steps that CAN SOMETIMES yield improvements
but which may well waste your time.  It MAY provide a more orderly
disk free-list which MAY produce a higher sequential-access rate
when sequentially re-reading files.  It also increases cylinder
co-residence of program blocks and therefore reduces seek-times
during demand-paging.

More than enuff said.  Sorry to bore ya.  Off to a flame-free vacation.

	JC McMillan -- att!mtunb!jcm -- Speaking only for hizzelf.
					(& 2 tired 2 proofread this.)