: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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
