On Mon, 14 Jan 2013 21:42:35 -0800
"Darrick J. Wong" <darrick.wong@xxxxxxxxxx> wrote:
> This patchset ("stable page writes, part 2") makes some key modifications to
> the original 'stable page writes' patchset. First, it provides creators
> (devices and filesystems) of a backing_dev_info a flag that declares whether or
> not it is necessary to ensure that page contents cannot change during writeout.
> It is no longer assumed that this is true of all devices (which was never true
> anyway). Second, the flag is used to relaxed the wait_on_page_writeback calls
> so that wait only occurs if the device needs it. Third, it fixes up the
> remaining disk-backed filesystems to use this improved conditional-wait logic
> to provide stable page writes on those filesystems.
>
> It is hoped that (for people not using checksumming devices, anyway) this
> patchset will give back unnecessary performance decreases since the original
> stable page write patchset went into 3.0. Sorry about not fixing it sooner.
>
> Complaints were registered by several people about the long write latencies
> introduced by the original stable page write patchset. Generally speaking, the
> kernel ought to allocate as little extra memory as possible to facilitate
> writeout, but for people who simply cannot wait, a second page stability
> strategy is (re)introduced: snapshotting page contents. The waiting behavior
> is still the default strategy; to enable page snapshotting, a superblock flag
> (MS_SNAP_STABLE) must be set. This flag is used to bandaid^Henable stable page
> writeback on ext3[1], and is not used anywhere else.
>
> Given that there are already a few storage devices and network FSes that have
> rolled their own page stability wait/page snapshot code, it would be nice to
> move towards consolidating all of these. It seems possible that iscsi and
> raid5 may wish to use the new stable page write support to enable zero-copy
> writeout.
>
> Thank you to Jan Kara for helping fix a couple more filesystems.
I have to say that 3d08bcc887 ("mm: Wait for writeback when grabbing
pages to begin a write") was a massive faceplant. How the heck did that
happen?
Looking back at the 19 May 2011 patchset, I see that we all managed to
avoid cc'ing the guy who wrote and designed that code and who introduced
the PageWriteback/wait_on_page_writeback() infrastructure to avoid exactly
the problem which 3d08bcc887 added. Sigh.
> This patchset has been tested on 3.8.0-rc3 on x64 with ext3, ext4, and xfs.
> What does everyone think about queueing this for 3.9?
This patchset lacks any performance testing results.
The patchset looks OK to me, but one thing I find unclear:
For clarity's sake, please provide a description of which filesystems
(and under which circumstances) will block behind writeback when
userspace is attempting to dirty a page. Both before and, particularly,
after this patchset. IOW, did everything get fixed?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
