On Wed, 16 Jan 2013 18:49:02 -0800 "Darrick J. Wong" [off-list ref] wrote:

quoted

The problem back in 2001 was that we held lock_page() across the
duration of page writeback, so if another thread came in and tried to
dirty the page, it would block on lock_page() until IO completion.  I
can't remember whether writeback would also block read().  Maybe it did,
in which case the effects of this patchset won't be as dramatic as were
the effects of splitting PG_lock into PG_lock and PG_writeback.

Now that you've stirred my memory, I /do/ dimly recall that Linux waited for
writeback back in the old days.  At least we'll be back to that.

Not really.  2.4 did writeback by walking a standalone list of
buffer_heads, without locking their containing page.  I removed all
that and did writeback of the page instead.  That immediately caused
this problem, because the 2.4 writepage held lock_page() across
writeout.  So I changed that to drop lock_page() immediately after
submission and added PG_writeback to flag the under-writeback state. 
The second change went in pretty much immediately - all within the
same 2.5.x release, probably.

As a side note, the average latency of a write to a non-DIF disk dropped down
to nearly nothing.

Some hard numbers in the changelog would be nice.  Did you try dbench-on-ext2?

quoted

Do we generate nice kernel messages (at mount or device-probe time)
which will permit people to work out which strategy their device/fs is
using?

No.  /sys/devices/virtual/bdi/*/stable_pages_required will tell you
stable pages are on or not, but so far only ext3 uses snapshots and the rest
just wait.  Do you think a printk would be useful?

Nope, if we can query the mode under /sys then that should be sufficient.