From owner-freebsd-hackers Sun Feb 24 10:10:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B0E6B37B404 for ; Sun, 24 Feb 2002 10:10:29 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1OI9v683497; Sun, 24 Feb 2002 10:09:57 -0800 (PST) (envelope-from dillon) Date: Sun, 24 Feb 2002 10:09:57 -0800 (PST) From: Matthew Dillon Message-Id: <200202241809.g1OI9v683497@apollo.backplane.com> To: Mike Silbersack Cc: Andrew Mobbs , Subject: Re: Test patch for msync/object-flushing performance (for stable) References: <20020224114508.P15264-100000@patrocles.silby.com> 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 :On Sun, 24 Feb 2002, Andrew Mobbs wrote: : :> vm.msync_flush_flags :> | 0 | 1 | 2 | 3 | :> -------+-------+-------+-------+-------| :> write | 519 | 517 | 1632 | 519 | :> sync | 2227 | 176 | 848 | 177 | : ^^^ :I don't get that one; any idea why bit 1 on for the first test performs so :differently from the other tests? Were these tests all run sequentially? :Maybe memory is becoming more fragmented as time goes on, causing that :optimization to not be able to work properly. : :Mike "Silby" Silbersack Bit 0 will always perform better then bit 1 for the case where a large portion of the mmap'd area is dirty. However, bit 0 (hard sequential) gives up if it cannot find dirty pages to sync after 16 pages. bit 1 can be thought of as a catch-all. If hard sequential fails we go back to scanning the memq (random). bit 1 tries to 'jump' to the next page based on the index and size of the previous cluster. bit 1 will 'help' if you have a huge mmap'd area with spotty dirty pages, but it does not spend a whole lot of time trying to force things to be sequential. I am leaning towards keeping both. I would like to improve bit 1's operation but keep in mind that the virtual size of a VM object can run into the terrabytes, so there is only so much we can do short of doing a full sort on object->memq (which is also a possibility at some later time). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message