Re: [RFC PATCH] discarding swap

[Hugh Dickins <hugh@veritas.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2773 bytes --]

On Wed, 10 Sep 2008, David Woodhouse wrote:
> On Wed, 2008-09-10 at 20:51 +0100, Hugh Dickins wrote:
> 
> blkdev_issue_discard() is for naïve callers who don't want to have to
> think about barriers. You might benefit from issuing discard requests
> without an implicit softbarrier, for swap.

Whilst I'd certainly categorize myself as a naïve caller, swap should
not be, and I now believe you're right that it would be better for
swap not to be using DISCARD_BARRIER there - thanks for noticing.

For that I think we'd want blk-barrier.c's blkdev_issue_discard() to
become __blkdev_issue_discard() with a fourth arg (either a boolean,
or DISCARD_BARRIER versus DISCARD_NOBARRIER), with blkdev_issue_discard()
and blkdev_issue_discard_nobarrier() functions inlined in blkdev.h.

I don't think it would be wise for mm/swapfile.c to duplicate
blkdev_issue_discard() without the _BARRIER: I expect that function
to go through a few changes as experience gathers with devices coming
onstream, changes we'd rather not track in mm; and I don't think mm
(beyond bounce.c) should get into request_queues and max_hw_sectors.

> Of course, you then have to ensure that a discard can't still be
> in-flight and actually happen _after_ a subsequent write to that page.

I was certainly terrified of a write sneaking down before the discard
when it was supposed to come after, and therefore took comfort from
the DISCARD_BARRIER - but was, I think, failing to understand that
it's for a filesystem which needs guarantees on the ordering
between data and metadata *in different areas* of the partition,
not an issue for swap at all.

Looking at what I ended up with, I had to put "wait_for_discard"
serialization in at the swap end anyway; and though I thought at the
time that the _BARRIER was saving me from waiting for completion
(only having to wait for completed submission), now I don't see
the _BARRIER as playing any part at all.

So long as the I/O schedulers guarantee that a WRITE bio submitted
to an area already covered by a DISCARD_NOBARRIER bio cannot pass that
DISCARD_NOBARRIER - where "already" means the submit_bio(WRITE, bio2)
is issued after the submit_bio(DISCARD_NOBARRIER, bio1) has returned
to caller (but its "I/O" of course not necessarily completed).

That seems a reasonable guarantee to me, and perhaps it's trivially
obvious to those who know their I/O schedulers; but I don't, so I'd
like to hear such assurance given.

(If there's a problem giving that assurance for WRITE, but it can be
given for WRITE_SYNC, that would suit me quite nicely too, because I'm
looking for a justification for WRITE_SYNC in swap_writepage(): Jens,
it makes those x86_64-tmpfs-swapping-on-CFQ cases a lot better.)

Hugh