Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!lll-lcc!vecpyr!amd!amdcad!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: 4.2 scheduler
Message-ID: <3043@sun.uucp>
Date: Thu, 28-Nov-85 15:52:42 EST
Article-I.D.: sun.3043
Posted: Thu Nov 28 15:52:42 1985
Date-Received: Sat, 30-Nov-85 06:51:36 EST
References: <1360@wanginst.UUCP> <879@psivax.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 32

> The critical routine 'namei' is quite slow, due to the need to recognise
> and correctly handle sockets.

Sockets?  "namei" doesn't know sockets from a hole in the ground!  "namei"
is slow on just about *any* UNIX system; it just happens to be slower in the
4.2BSD file system as opposed to the V7 file system that all other UNIXes
use because of the longer names and more complicated directory structure,
and because you may encounter symbolic links which can lengthen the path you
end up searching.

> Also pipes now have a few more layers of software to run them.

To be precise, pipes now work through the networking code rather than
through the file system code.

> The net result is that a 4.2 system spends 30 to 50% of its time in the
> kernel(verify this by running vmstat)!! This is quite high.

Well, it *can* spend that much time in the kernel, depending on what you're
doing.  30 to 50% isn't *that* high (I've heard MVS spends at least 50% of a
370-family machine's cycles); the paper Berkeley put out on 4.2/4.3
performance tuning indicated that 4.1 spent about 45% of its time in the
kernel, 4.2 spent about 55% of its time there, and that they'd cut it back
to 45% with their tuning.

> As I understand it 4.3 has corrected many of these problems.

Yes; they've sped up "namei" with a cache of name-to-inode translations, as
well as other changes.  They may have sped up the flow of data through the
network code, which would speed up pipes (and TCP transfers, and...).

	Guy Harris