From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 12 Sep 2008 18:46:50 +0100 (BST) From: Hugh Dickins Subject: Re: [RFC PATCH] discarding swap In-Reply-To: <1221236528.21323.22.camel@macbook.infradead.org> Message-ID: References: <20080910173518.GD20055@kernel.dk> <1221082117.13621.25.camel@macbook.infradead.org> <1221228567.3919.35.camel@macbook.infradead.org> <1221236528.21323.22.camel@macbook.infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: David Woodhouse Cc: Jens Axboe , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org List-ID: On Fri, 12 Sep 2008, David Woodhouse wrote: > On Fri, 2008-09-12 at 16:52 +0100, Hugh Dickins wrote: > > On Fri, 12 Sep 2008, David Woodhouse wrote: > > > On Fri, 2008-09-12 at 13:10 +0100, Hugh Dickins wrote: > > > > 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 - ... > > > > > > No, that's the point. the I/O schedulers _don't_ give you that guarantee > > > at all. They can treat DISCARD_NOBARRIER just like a write. That's all > > > it is, really -- a special kind of WRITE request without any data. > > > > Hmmm. In that case I'll need to continue with DISCARD_BARRIER, > > unless/until I rejig swap allocation to wait for discard completion, > > which I've no great desire to do. I'll leave it to Jens to comment on your reply, but I'd like to go back and add in a further, orthogonal concern or misunderstanding here. Am I right to be a little perturbed by blk_partition_remap() and the particular stage at which it's called? Does it imply that a _BARRIER on swap would have the effect of inserting a barrier into, say, root and home I/Os too, if swap and root and home were in separate partitions on the same storage? Whereas a filesystem would logically only want a barrier to span its own partition? (I'm ignoring md/dm.) Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org