Date: Tue, 22 Jun 2004 23:58:24 -0400 From: "Mikhail T." <mi@aldan.algebra.com> To: Peter Wemm <peter@wemm.org> Cc: Mikhail Teterin <mi+kde@aldan.algebra.com> Subject: Re: read vs. mmap (or io vs. page faults) Message-ID: <200406222358.24573@Misha> In-Reply-To: <200406222027.30702.peter@wemm.org> References: <Pine.BSF.4.21.0406201716191.23541-100000@InterJet.elischer.org> <200406220108.31366@aldan> <200406222027.30702.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=D7=A6=D7=D4=CF=D2=CF=CB 22 =DE=C5=D2=D7=C5=CE=D8 2004 23:27, Peter Wemm, = =F7=C9 =CE=C1=D0=C9=D3=C1=CC=C9: =3D On Monday 21 June 2004 10:08 pm, Mikhail Teterin wrote: =3D The amount of "work" for the kernel to do a read() and a high-speed =3D memory copy is much less than the cost of taking a page fault, running =3D a whole bunch of really really nasty code in the vm system, repairing =3D the damage from the page fault, updating the process paging state and =3D 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? =3D The numbers you're posting are a simple reflection of the fact that =3D the read syscall path has fewer (and less expensive) instructions to =3D 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? =3D Some operating systems implemented read(2) as an internal in-kernel =3D mmap/fault/copy/unmap. Naturally, that made mmap look fast compared to =3D read, at the time. But that isn't how it is implemented in FreeBSD. =3D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406222358.24573>