Date: Wed, 28 Jun 2000 23:52:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jrs@enteract.com (John Sconiers) Cc: dillon@apollo.backplane.com (Matthew Dillon), luoqi@watermarkgroup.com (Luoqi Chen), jasone@canonware.com, smp@FreeBSD.ORG Subject: Re: SMP meeting summary Message-ID: <200006282352.QAA08247@usr08.primenet.com> In-Reply-To: <Pine.NEB.3.96.1000626145024.51277A-100000@shell-2.enteract.com> from "John Sconiers" at Jun 26, 2000 02:56:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> Quick question. I've been reading this as well as past threads and > understand the merit and functionality of the new SMP model. However, how > much (if any) will Performance on both single and multi cpu machines > improve after this change?? Will the new systme use up more resources(ie > memory, swap, cpu) in single and multi CPU configurations?? I apologize > if this has already been brought up. Here's my lab experience with UnixWare from Novell: Making the kernel preemptable and the UFS (SVR4's FFS) reentrant sped up UnixWare 2.0 SMP over Unixware 1.0 UP ~150%. That's measured, in a lab. UnixWare uses a method called DOW or Delayed Ordered Writes (the ReiserFS is in violation of this patent, if SCO wanted to push it); it is inferior to Soft Updates. It introduces a synchronization point, rather than an update, when a modification would require an update occur and a dependency entered into the dependency tree. In addition, UnixWare did (does) not have a unified VM and buffer cache. The per vnode working set quota code I had proposed to resolve the "move mouse, wiggle cursor" problem with page stealing by a single hungry process was not adopted, and a fixed scheduling class was adopted instead (giving X the cycles to page itself back in -- stealing the pages back -- in the process), so the results were poorer than they would have otherwise been. Combined, these mean that this lab test was biased against the speed improvement. On a reasonable non-benchmark workload where there were no stalling points being introduced by all processes whacking the same directory, and where no single process was allowed to force another out of core via page steal DOS attacks, and where the buffer cache and VM system didn't result in extra copies and "useless" reserve memory for one system or another, I'd expect this to increase to 250% or more (I was able to get ~190% overall by introducing my working set quota changes on a per process, rather than a per vnode, basis for experimental purposes). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006282352.QAA08247>