[PATCH 3 of 3] revlog: read index data using mmap

[Bryan O'Sullivan]

So using mmap from /dev/zero means "give me zero-filled memory", and the
Linux kernel special-cases this to perform no I/O at all.

It is most definitely not safe to use mmap for I/O on all files by default,
as the setup and teardown overhead is very high. If you actually measure
that strategy, you will notice a big performance regression.

I would expect suitably tuned explicit file I/O to be always be faster than
mmap, although you'd have to amortize the I/O across multiple smaller
batched reads to achieve this for truly large files, thus leading to a
significant increase in complexity.


On Tue, Oct 4, 2016 at 7:04 PM, Jun Wu <quark at fb.com> wrote:

> Excerpts from Pierre-Yves David's message of 2016-10-04 18:28:54 +0200:
> > I remember Matt making arguments against the use of mmap in multiple
> > occurrence in the past. I can find the details again
>
> I did a google search "mpm mmap site:www.mercurial-scm.org/pipermail/" and
> read all of the 16 results.
>
> He himself used mmap to speed up things [0]. So please don't have
> preconceived opinion that mmap is bad.
>
> It seems what he was worrying about is exactly what I mentioned in the
> reply
> [1] to Augie's mail - with random access pattern things can be slower [2].
> And it seems Linux's mmap implementation is smart enough to avoid worst
> cases [3]. So I think it's probably safe to at least enable it for Linux by
> default.
>
> I will get some numbers soon(tm).
>
> [0]: https://www.mercurial-scm.org/pipermail/mercurial/2005-May/
> 000071.html
> [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/
> 2016-October/088747.html
> [2]: https://www.mercurial-scm.org/pipermail/mercurial/2005-May/
> 000096.html
> [3]: https://www.mercurial-scm.org/pipermail/mercurial-devel/
> 2012-July/042615.html
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161005/23bfeb0c/attachment.html>