[Top] [All Lists]

Re: XFS performance issues: O_DIRECT and Linux 2.6.6+

To: James Foris <james.foris@xxxxxxxxxx>
Subject: Re: XFS performance issues: O_DIRECT and Linux 2.6.6+
From: Nathan Scott <nathans@xxxxxxx>
Date: Wed, 15 Sep 2004 11:50:02 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <41472212.1090605@xxxxxxxxxx>
References: <411A8410.2030000@xxxxxxxxxx> <20040910041106.GA14336@frodo> <4144B19A.2020407@xxxxxxxxxx> <4145D141.1040907@xxxxxxxxxx> <20040914095914.A4118499@xxxxxxxxxxxxxxxxxxxxxxxx> <41472212.1090605@xxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.3i
Hi James,

On Tue, Sep 14, 2004 at 11:53:38AM -0500, James Foris wrote:
> ...
> I put a drop-through printk in mm/filemap.c to report when O_DIRECT hits the
> following:
>       /*
>            * If we get here for O_DIRECT writes then we must have fallen 
>            through
>             * to buffered writes (block instantiation inside i_size).  So 
>             we sync
>             * the file data here, to try to honour O_DIRECT expectations.
>             */
>             if (unlikely(file->f_flags & O_DIRECT) && written)
>                    status = filemap_write_and_wait(mapping);

Hmmm... very interesting.

> So, what appears to be happening is that the new logic is treating ANYTHING 
> past the first
> transaction (first 150K of the write) as a residual requiring 
> buffering/fully syncronous
> operation reguardless of  boundry or size - which says O_DIRECT no longer 
> works on
> files greater than 150K.
> Does this analysis sound about right to you ?

Sort of, I think you're on the right track.  I'll try to get hold of a fast
machine today to see if I can see this behavior (my usual test machine is
quite plodding, and I think thats why I'm not reproducing this atm).

But, if your test program is creating the file each time and not doing more
than just sequential writes (not writes into holes), then if you're getting
into that filemap_write_and_wait call above I suspect that will be the root
cause of your problem (i.e, we should not be falling back to buffered for
your test case, if your program is doing what I think its doing).

To check this, if you change fs/direct-io.c::get_more_blocks to never set
"beyond_eof" to one, does the problem go away?



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