[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45BCBECE.4080405@tmr.com>
Date: Sun, 28 Jan 2007 10:18:38 -0500
From: Bill Davidsen <davidsen@....com>
To: linux-kernel@...r.kernel.org
Cc: Michael Tokarev <mjt@....msk.ru>, Phillip Susi <psusi@....rr.com>,
Linus Torvalds <torvalds@...l.org>, Viktor <vvp01@...ox.ru>,
Aubrey <aubreylee@...il.com>, Hua Zhong <hzhong@...il.com>,
Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org,
hch@...radead.org, kenneth.w.chen@in
Subject: Re: O_DIRECT question
Denis Vlasenko wrote:
> On Friday 26 January 2007 19:23, Bill Davidsen wrote:
>> Denis Vlasenko wrote:
>>> On Thursday 25 January 2007 21:45, Michael Tokarev wrote:
>>>> Phillip Susi wrote:
[...]
>>>> But even single-threaded I/O but in large quantities benefits from O_DIRECT
>>>> significantly, and I pointed this out before.
>>> Which shouldn't be true. There is no fundamental reason why
>>> ordinary writes should be slower than O_DIRECT.
>>>
>> Other than the copy to buffer taking CPU and memory resources.
>
> It is not required by any standard that I know. Kernel can be smarter
> and avoid that if it can.
Actually, no, the whole idea of page cache is that overall system i/o
can be faster if data sit in the page cache for a while. But the real
problem is that the application write is now disconnected from the
physical write, both in time and order.
No standard says the kernel couldn't do direct DMA, but since having
that required is needed to guarantee write order and error status linked
to the actual application i/o, what a kernel "might do" is irrelevant.
It's much easier to do O_DIRECT by actually doing the direct i/o than to
try to catch all the corner cases which arise in faking it.
--
Bill Davidsen <davidsen@....com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists