On Wed, 16 Jan 2013 18:49:02 -0800 "Darrick J. Wong" <darrick.wong@xxxxxxxxxx> wrote: > > > > 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? > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
