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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
