Date: Sat, 25 Mar 2006 11:03:33 -0800 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Mikhail Teterin <mi+kde@aldan.algebra.com> Cc: alc@freebsd.org, Peter Jeremy <peterjeremy@optushome.com.au>, Mikhail Teterin <mi+mx@aldan.algebra.com>, stable@freebsd.org Subject: Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS) Message-ID: <20060325190333.GD7001@funkthat.com> In-Reply-To: <200603250920.14208@aldan> References: <200603232352.k2NNqPS8018729@gate.bitblocks.com> <200603241518.01027.mi%2Bmx@aldan.algebra.com> <20060325103927.GE703@turion.vk2pj.dyndns.org> <200603250920.14208@aldan>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote this message on Sat, Mar 25, 2006 at 09:20 -0500:
> = The downside is that touching an uncached page triggers a trap which may
> = not be as efficient as reading a block of data through the filesystem
> = interface, and I/O errors are delivered via signals (which may not be as
> = easy to handle).
>
> My point exactly. It does seem to be less efficient *at the moment* and I
> am trying to have the kernel support for this cleaner method of reading
> *improved*. By convincing someone with a clue to do it, that is... :-)
I think the thing is that there isn't an easy way to speed up the
faulting of the page, and that is why you are getting such trouble
making people believe that there is a problem...
To convince people that there is a problem, you need to run benchmarks,
and make code modifications to show that yes, something can be done to
improve the performance...
The other useful/interesting number would be to compare system time
between the mmap case and the read case to see how much work the
kernel is doing in each case...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060325190333.GD7001>