>You get an additional process slot, which is not to be sneezed at.
>More significant, though, you have a guarantee that data is flushed
>back within some short period of time, no matter what state the system
You don't care to run update always with the same delta-time between
different runs. update does "sync some old buffer to disk". If you'll
delay the call of sync_old_buffers() then as worse the next time you'll
sync to disk some more dirty buffer.
The stability of the VM system is enforced by bdflush/kswapd and not
from uptime.
>is in. You don't seem to think this is important, but to anyone who
>maintains a server with key data on it, it is *critical*.
If you need filesystem integrity after a crash (or better after a power
fail... ;), then you need a fault toulerant fs and not ext2. update
can't save you, it can only alleviate the damage.
>I also think that with update rolled into bdflush, it will be possible
>to do the job faster and with less bottlenecking. See below.
You sometime force mark_dirty_buffers() to wait all dirty
buffers to be flushed away before allowing it to go ahead.
>block; instead you call flush_dirty_buffers directly. I'm not sure
>that's a good idea; can you justify it?
Think if bdflush was writing the last bdflush_param.ndirty buffer. You'll
issue a sleep_on() but you'll get a wakeup without waiting that some more
buffer is been synced back to disk. And my way will avoid many task switch
ping-pong.
>where `2.2.8+p' is 2.2.8 plus the patch at the end of this message.
Please let me see the numbers of 2.2.8_andrea1.bz2 doing the same on the
same heardware, I would be interested.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/