From: Bill Davidsen <davidsen@tmr.com>
To: Robert Love <rml@novell.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mmap vs. O_DIRECT
Date: Thu, 11 Nov 2004 09:50:02 -0500 [thread overview]
Message-ID: <41937C1A.30800@tmr.com> (raw)
In-Reply-To: <1100121230.4739.1.camel@betsy.boston.ximian.com>
Robert Love wrote:
> On Tue, 2004-11-09 at 19:05 -0500, Bill Davidsen wrote:
>
>>I have an application which does a lot of mmap to process its data. The
>>huge waitio time makes me think that mmap isn't doing direct i/o even
>>when things are alligned. Before I start poking the code, is there a
>>reason why direct is not default for i/o in page-size transfers on page
>>size file offsets? I don't have source code, but the parameters of the
>>mmap all seem to satisfy the allignment requirements.
>>
>>I realize there may be a reason for forcing the i/o through kernel
>>buffers, or for not taking advantage of doing direct i/o whenever
>>possible, it just doesn't jump out at me.
>
>
> Direct I/O (O_DIRECT) will almost assuredly increase I/O wait and
> degrade I/O performance, not improve it.
>
Sorry, I have to totally disagree, based on a year's experience with 30+
usenet servers which can be run with or without direct. Without direct
the data for every access is copied through the system buffers before
reaching the user program. By using O_DIRECT the waitio time reported
dropped (400-500 users/server) from 40+% to about 14%.
Since the same volume of data and the same number of i/o are being done,
I can't see how doing an extra copy could possibly do anything good!
> I don't think direct I/O is what you want and I am sure that we don't
> want aligned mmaps to not go through the page cache and be synchronous.
Having seen the results in actual experience using seek/read access, I
am interested in getting the same benefits from the application using
mmap, preferably without rewriting the application to use direct access
explicitly.
I miss your point about synchronous, with hundreds of clients doing
small reads against a 10TB database, the benefit of pushing them through
the page cache isn't obvious. No particular data are in memory long
enough to have much chance of being shared, so it looks like overhead to
me. Feel free to educate me.
I certainly DO want to put more users per server, and direct I/O has
proven itself in actual use. I'm not sure why you think the double copy
is a good thing, but I have good rea$on to want more users per server.
Alan: point on MAP_SHARED taken.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2004-11-11 14:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-10 0:05 mmap vs. O_DIRECT Bill Davidsen
2004-11-10 21:13 ` Robert Love
2004-11-11 14:50 ` Bill Davidsen [this message]
2004-11-11 15:41 ` Robert Love
2004-11-11 17:13 ` Robert Love
2004-11-11 17:19 ` Avi Kivity
2004-11-11 17:22 ` Robert Love
2004-11-10 22:19 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41937C1A.30800@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@novell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox