From owner-freebsd-hackers Sun Feb 24 7:37:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 3B43B37B402 for ; Sun, 24 Feb 2002 07:37:19 -0800 (PST) Received: from pool0068.cvx40-bradley.dialup.earthlink.net ([216.244.42.68] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16f0i6-0000rk-00; Sun, 24 Feb 2002 07:37:10 -0800 Message-ID: <3C79089B.10AD892C@mindspring.com> Date: Sun, 24 Feb 2002 07:36:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Mobbs Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Test patch for msync/object-flushing performance (for stable) References: <15478.31998.459219.178549@chiark.greenend.org.uk> <200202222042.g1MKg4u22700@apollo.backplane.com> <200202222201.g1MM1f431236@apollo.backplane.com> <15481.61.57511.222531@chiark.greenend.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrew Mobbs wrote: > vm.msync_flush_flags > | 0 | 1 | 2 | 3 | > -------+-------+-------+-------+-------| > write | 519 | 517 | 1632 | 519 | > sync | 2227 | 176 | 848 | 177 | > -------+-------+-------+-------+-------| > write | 514 | 517 | 518 | 516 | > sync | 2215 | 175 | 2219 | 176 | > -------+-------+-------+-------+-------| > write | 511 | 649 | 517 | 513 | > sync | 2209 | 125 | 2223 | 176 | > -------+-------+-------+-------+-------| > write | 514 | 518 | 515 | 517 | > sync | 2217 | 176 | 2209 | 176 | > -------+-------+-------+-------+-------| > write | 516 | 516 | 517 | 518 | > sync | 2219 | 176 | 2222 | 177 | > > Nearly 13 times improvement in sync times, very nice. ^ ^ Wow. Pessimial... ----------'-------' Looks like most (but not all) gets recovered if you also set the other flag. This argues against the "optimization" enabled by bit 1, but OK's the one for bit 0. Matt... is there a situation which you can provide a small test for that doesn't make the bit 1 change look like a total lose? You might see it be a good idea in an unpack of the ports tree over itself (for example), but right now it looks like a no-brainer to leave it out, and default the bit 0 to on. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message