Date: Wed, 15 Feb 1995 22:34:33 +0000 From: Ed Hudson <elh@p5.spnet.com> To: davidg@Root.COM, hackers@FreeBSD.org Cc: elh@p5.spnet.com Subject: Re: 950210-SNAP, VM Free Message-ID: <199502152234.WAA00285@p5.spnet.com> In-Reply-To: Your message of "Wed, 15 Feb 1995 15:50:41 PST." <199502152350.PAA00559@corbin.Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502152234.WAA00285>