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

вівторок 22 червень 2004 23:27, Peter Wemm, Ви написали:
= On Monday 21 June 2004 10:08 pm, Mikhail Teterin wrote:

= The amount of "work" for the kernel to do a read() and a high-speed
= memory copy is much less than the cost of taking a page fault, running
= a whole bunch of really really nasty code in the vm system, repairing
= the damage from the page fault, updating the process paging state and
= restarting the instruction.

Does the code _have_ to be "really really nasty", or it just _happened_
to be that way for historical reasons -- like this being a very complex
issue, and, once it worked, no one really wanted to mess with it?

= The numbers you're posting are a simple reflection of the fact that
= the read syscall path has fewer (and less expensive) instructions to
= execute compared to the mmap fault paths.

Why, then, is the total number of CPU seconds (kernel+user) favorable
towards mmap on CPU bound machines and about the same on IO bound? May
be, because all that CPU work, you are describing, is also much faster
on the modern CPUs?

= Some operating systems implemented read(2) as an internal in-kernel
= mmap/fault/copy/unmap. Naturally, that made mmap look fast compared to
= read, at the time. But that isn't how it is implemented in FreeBSD.

= mmap is more valuable as a programmer convenience these days.

I figured :-( It is very convenient. As such, it should be wider used
(because it leads to cleaner code), but that wouldn't come until it also
offers the performance comparable to the less clean method(s)... Yours,

	-mi