Re: read vs. mmap (or io vs. page faults)

On Sunday 20 June 2004 08:16 pm, Julian Elischer wrote:
= On Sun, 20 Jun 2004, Matthew Dillon wrote:
[...]
= >     It is usually a bad idea to try to populate the page table with
= >     all resident pages associated with the a memory mapping, because
= >     mmap() is often used to map huge files...
[...]

= pre-faulting is best done by a worker thread or child process, or it
= will just slow you down..

Read is also used for large files sometimes, and never tries to prefetch
the whole file at once. Why can't the same smarts/heuristics be employed
by the page-fault handling code -- especially, if we are so proud of our
unified caching?

If anything mmap/madvise provide the kernel with _more_ information than
read -- kernel just does not use it, it seems.

According to my tests (`fgrep string /huge/file' vs. `fgrep --mmap
string /huge/file') the total CPU time is much less with mmap. But
sometimes the total "wall clock" time is longer with itj because the CPU
is underutilized, when using the mmap method.

		4.8-stable on Pentium2-400MHz
	mmap: 21.507u 11.472s 1:27.53 37.6%   62+276k 99+0io 44736pf+0w
	read: 10.619u 23.814s 1:17.67 44.3%   62+274k 11255+0io 0pf+0w

		recent -current on dual P2 Xeon-450MHz (mmap WINS -- SMP?)
	mmap: 12.482u 12.872s 2:28.70 17.0%   74+298k 23+0io 46522pf+0w
	read: 7.255u 16.366s 3:27.07 11.4%    70+283k 44437+0io 7pf+0w

		recent -current on a Centrino-laptop P4-1GHz (NO win at all)
	mmap: 4.197u 3.920s 2:07.57 6.3%      65+284k 63+0io 45568pf+0w
	read: 3.965u 4.265s 1:50.26 7.4%      67+291k 13131+0io 17pf+0w

		Linux 2.4.20-30.9bigmem dual P4-3GHz (with a different file)
	mmap: 2.280u 4.800s 1:13.39 9.6%      0+0k 0+0io 512434pf+0w
	read: 1.630u 2.820s 0:08.89 50.0%     0+0k 0+0io 396pf+0w

The attached md5-computing program is more CPU consuming than fgrep. It
wins with mmap even on the "sceptical" Centrino-laptop -- presumably,
because MD5_Update is not interrupted as much and remains in the
instruction cache:

	read: 22.024u 8.418s 1:28.44 34.4%    5+166k 10498+0io 4pf+0w
	mmap: 21.428u 3.086s 1:23.88 29.2%    5+170k 40+0io 19649pf+0w

Once mmap-handling is improved, all sorts of whole-file operations
(bzip2, gzip, md5, sha1) can be made faster...

	-mi