From owner-freebsd-stable@FreeBSD.ORG Wed Apr 12 21:55:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 165A616A402 for ; Wed, 12 Apr 2006 21:55:14 +0000 (UTC) (envelope-from crossd@cs.rpi.edu) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1C143D5F for ; Wed, 12 Apr 2006 21:55:12 +0000 (GMT) (envelope-from crossd@cs.rpi.edu) Received: from wireless-50.dyn.cs.rpi.edu (wireless-50.dyn.cs.rpi.edu [128.213.51.50]) (authenticated bits=0) by cliffclavin.cs.rpi.edu (8.13.6/8.13.6) with ESMTP id k3CLt3UB093492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 12 Apr 2006 17:55:09 -0400 (EDT) From: "David E. Cross" To: Garance A Drosihn In-Reply-To: References: <1144795412.81364.18.camel@localhost> <20060412040326.GA94545@xor.obsecurity.org> <443D3C94.7040404@samsco.org> Content-Type: text/plain Date: Wed, 12 Apr 2006 21:55:00 +0000 Message-Id: <1144878900.52816.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.56 on 128.213.1.9 Cc: freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: swap performance under 6.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 21:55:14 -0000 Yes, I wouldn't be at all surprised to find out that my 6.1 partition has a bad block in .. say.. libc that's delaying reads and causing me trouble, I just remember installing 6.1 and thinking "OUCH". I get the impression that this is a latency issue more then a bandwidth issue (responsiveness vs performance). so I think that any long running test to see how effecitvely we swap isn't going to show anything. I could totally re-partition and get 4.x, 5.x and 6.x all on concurrently if that would help. But I think I would need a good test program to have waiting in the wings to quantitatively measure the differences; anyone have any ideas? (and yes, as Garance quoted, swap partition is shared) -- David E. Cross On Wed, 2006-04-12 at 14:46 -0400, Garance A Drosihn wrote: > At 11:44 AM -0600 4/12/06, Scott Long wrote: > >Garance A Drosihn wrote: > >>At 12:03 AM -0400 4/12/06, Kris Kennaway wrote: > >>> > >>>I didn't think this was a 6.1 regression compared to 6.0, > >>>but 6.x compared to 4.x. It would be good to try and > >>>quantify any performance differences here - so far it's > >>>just a bunch of people's subjective opinions (including > >>>mine) after upgrading from 4.x. > >> > >>In Dave's case, the tests are explicitly 6.0-release vs > >>6.1-@april-5th. Those are the two installations he has on > >>his laptop, which he is comparing to each other via dual- > >>booting. The thing is, he's not sure how to get the numbers > >>to back up the performance "feel" that he's experiencing. > > > >Is he using the same swap partitions for both of the dual-booted > >OS's? If not, he's measuring the speed of the disk at the outer > >tracks vs the inner tracks. There may indeed be performance > >issues in the OS, but they need to be quanitfied in a controlled > >environment and not be subject to things like this. > > David has been talking about this on a local chat system for a > week or two now, but apparently he doesn't track the freebsd > mailing lists as much as I do... > > From a comment he made on that chat system: > > - As an additional datapoint, I am actually sharing the > - swap partition between the 6.0 and 6.1 partitions, so > - that should eliminate any problems there. Now is the > - 6.1 partition itself has disk issues it could still > - explain my problems > > - OS's are on the same physical drive, different partition, > - GENERIC for 6.0 and 6.1 > > It wouldn't surprise either me or David if this was something > specific to his system or his setup, but we're running out of > ideas of what that would be. (and we're both busy juggling a > few other things in our main jobs, so we're probably not as > focused on this as issue we would like to be...). >