From: Peter Zaitsev <pz@spylog.ru>
To: linux-kernel@vger.kernel.org
Subject: MMAP vs READ/WRITE
Date: Wed, 13 Mar 2002 16:17:18 +0300 [thread overview]
Message-ID: <861732271654.20020313161718@spylog.ru> (raw)
Hello linux-kernel,
wrote you about possibilities of using MMAP in performing I/O.
So I decided to check if it really gives any benefit under Linux. I
used stock system (IDE PIII-500, 768M RAM) and 2.4.19pre1aa1
I've tested 2 file sizes - 200M and 2000M to see how the fact
content fits to cache will affect the performance. I used 1Kb
blocks to have it the same as MYISAM uses for keycache.
There were two tests. One is to read file convent sequentially and
other was to random I/O - read and write to random locations in
1K sizes. The reads/writes was it 50/50 proportion. The number of
random IOs was 10000. File system used was EXT3.
Before each test the cache was brought to stable state by
"cat test.dat > /dev/null"
2000M
Test Time Best Time Worst User time System time
Seq. read() 1m28.706s 2m20.358s 0m0.920s 0m26.550s
Seq mmap() 2m4.718s 4m41.674s 0m8.100s 0m11.040s
Rnd read() 1m49.413s 2m46.212s 0m0.010s 0m0.470s
Rnd mmap() 1m17.349s 2m13.482s 0m0.070s 0m0.430s
200M
Test Time Best Time Worst User time System time
Seq. read() 0m1.465s 0m1.481s 0m0.050s 0m1.290s
Seq mmap() 0m1.206s 0m1.518s 0m0.980s 0m0.130s
Rnd read() 0m0.130s 0m0.134s 0m0.020s 0m0.100s
Rnd mmap() 0m0.079s 0m0.082s 0m0.050s 0m0.020s
2000M 4K block (to compare)
Test Time Best Time Worst User time System time
Seq. read() 1m28.328s 2m11.609s 0m0.260s 0m23.510s
Seq mmap() 2m32.768s 4m28.321s 0m8.090s 0m11.240s
Rnd read() 1m6.351s 1m46.149s 0m0.040s 0m0.400s
Rnd mmap() 1m10.707s 1m57.281s 0m0.280s 0m0.510s
200M 32 byte block (to compare)
Test Time Best Time Worst User time System time
Seq. read() 0m8.076s 0m9.404s 0m1.730s 0m6.620s
Seq mmap() 0m1.227s 0m1.237s 0m1.140s 0m0.080s
Rnd read() 0m0.074s 0m0.085s 0m0.010s 0m0.070s
Rnd mmap() 0m0.029s 0m0.030s 0m0.010s 0m0.020s
So I would say mmap is not really optimized nowdays in Linux and so
read() may be wining in cases it should not. May be read-ahead is
used with read and is not used with mmap.
P.S if you're interested I can send you complete source
--
Best regards,
Peter mailto:pz@spylog.ru
next reply other threads:[~2002-03-13 13:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 13:17 Peter Zaitsev [this message]
2002-03-13 13:41 ` Oleg Drokin
2002-03-13 13:58 ` Rik van Riel
2002-03-13 14:48 ` Re[2]: " Peter Zaitsev
2002-03-13 14:58 ` Rik van Riel
2002-03-13 15:17 ` Re[3]: " Peter Zaitsev
2002-03-14 9:27 ` Re[2]: " Peter Zaitsev
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=861732271654.20020313161718@spylog.ru \
--to=pz@spylog.ru \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®