xfs
[Top] [All Lists]

Re: sleeps and waits during io_submit

To: Avi Kivity <avi@xxxxxxxxxxxx>
Subject: Re: sleeps and waits during io_submit
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 1 Dec 2015 11:41:39 -0800
Cc: Brian Foster <bfoster@xxxxxxxxxx>, Glauber Costa <glauber@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <565DF472.8080101@xxxxxxxxxxxx>
References: <20151201131114.GA26129@xxxxxxxxxxxxxxx> <565DA784.5080003@xxxxxxxxxxxx> <20151201145631.GD26129@xxxxxxxxxxxxxxx> <565DBB3E.2010308@xxxxxxxxxxxx> <20151201160133.GE26129@xxxxxxxxxxxxxxx> <565DC613.4090608@xxxxxxxxxxxx> <20151201162958.GF26129@xxxxxxxxxxxxxxx> <565DD449.5090101@xxxxxxxxxxxx> <20151201185113.GG26129@xxxxxxxxxxxxxxx> <565DF472.8080101@xxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
On Tue, Dec 01, 2015 at 09:26:42PM +0200, Avi Kivity wrote:
> It's basically the same thing.  To to this, we'd have get_block either
> return the block's address (if it was in some metadata cache), or, if it was
> not, issue an I/O that fills (part of) that cache, and as its completion
> function, a continuation that reruns __blockdev_direct_IO from the point it
> was stopped so it can submit the data I/O (if the metadata cache was
> completely updated) or issue the next I/O aiming to fill that metadata
> cache, if it was not.

We did something this for blocking reads with great results, and it could be
done similarly for direct I/O I think:

        https://lwn.net/Articles/612483/

Unfortunately Andrew shut it down for odd reasons so it didn't get in.

<Prev in Thread] Current Thread [Next in Thread>