Date: Sun, 24 Feb 2002 10:09:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: Andrew Mobbs <andrewm@chiark.greenend.org.uk>, <hackers@FreeBSD.ORG> Subject: Re: Test patch for msync/object-flushing performance (for stable) Message-ID: <200202241809.g1OI9v683497@apollo.backplane.com> References: <20020224114508.P15264-100000@patrocles.silby.com>
index | next in thread | previous in thread | raw e-mail
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202241809.g1OI9v683497>