From owner-freebsd-hackers  Wed Feb 15 22:36:39 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id WAA12603 for hackers-outgoing; Wed, 15 Feb 1995 22:36:39 -0800
Received: from p5.spnet.com (elh.com [204.156.130.1]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id WAA12597 for <hackers@FreeBSD.org>; Wed, 15 Feb 1995 22:36:37 -0800
Received: from localhost (localhost [127.0.0.1]) by p5.spnet.com (8.6.9/8.6.6) with SMTP id WAA00285; Wed, 15 Feb 1995 22:34:34 GMT
Message-Id: <199502152234.WAA00285@p5.spnet.com>
X-Authentication-Warning: p5.spnet.com: Host localhost didn't use HELO protocol
To: davidg@Root.COM, hackers@FreeBSD.org
cc: elh@p5.spnet.com
Subject: Re: 950210-SNAP, VM Free 
In-reply-to: Your message of "Wed, 15 Feb 1995 15:50:41 PST."
             <199502152350.PAA00559@corbin.Root.COM> 
Date: Wed, 15 Feb 1995 22:34:33 +0000
From: Ed Hudson <elh@p5.spnet.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


howdy.

	
>  From: David Greenman <davidg@Root.COM>
>
>     The thing to compare this to would be a 2.0 system. I think you'll find
>  that it is always better. I believe the non-optimal performance you're seeing
>  is caused by our algorithm for deciding how much file data to cache. It tries

	i've tried this under 2.0R.

 --->>>	I  don't get the system slow down problem with
 --->>> accumulated system time!


	here are the results:

	**2.0R**
	
	small compile, fresh boot:
	31.5u 6.5s 0:48.59 78.4% 898+865k 197+452io 70pf+0w
	31.8u 6.8s 0:42.89 90.2% 883+851k 0+446io 0pf+0w

	small compile, after:
	31.6u 6.7s 0:41.85 91.8% 883+852k 5+428io 0pf+0w
	31.8u 6.5s 0:41.95 91.7% 884+850k 0+435io 0pf+0w

	medium compile, fresh boot:
	115.1u 25.8s 2:45.41 85.2% 836+1007k 334+1443io 14pf+0w

	medium compile, fresh after:
	114.3u 27.3s 2:42.34 87.2% 834+1002k 279+1408io 0pf+0w

	/bin/ls -LFC, 	fresh boot:
	0.0u 0.0s 0:00.04 250.0% 80+147k 0+0io 0pf+0w

	/bin/ls -LFC, 	fresh after:
	0.0u 0.0s 0:00.11 36.3% 231+447k 0+0io 0pf+0w


	again, for comparison, here are some 'after' results
	with 950210SNAP:

  sml:	31.4u 6.1s 0:43.56 86.4% 918+888k 11+473io 0pf+0w
  med:	113.0u 25.9s 4:07.75 56.0% 862+1040k 5571+1564io 14pf+0w
  ls:	0.0u 0.0s 0:00.57 14.0% 205+352k 24+0io 0pf+0w


  	all of the 950210-SNAP fresh boot numbers are essentially
	the same as the 2.0R


	the hardware configuration is a little different between
	the two OS tests.  the source trees being compiled are
	always on the same disk, a quantum 2100-S.

	in the case of 2.0R, the os is on the same disk as the
	source tree.  in the case of 950210-SNAP, the os is on
	a different disk (MICROP  2217) , and the quantum is
	mounted.  both disks supply swap partitions in the SNAP
	case, and only the quantum in the 2.0R case.

	let me also stress that the kernel's that i'm running
	are, in both cases, my own, freshly derived from the
	GENERIC sources, with irrelevent hardware, and a few
	other options removed or added.  if there are any
	option configurations that may affect this problem,
	then that could be an issue as well.

	the machine i'm running on has 32mby of phys memory.

	thanks again for looking at this.
	i'd be very pleased to run any experiment you might suggest;
	2.0R vs SNAP is only a reboot away.

			-elh