mmap changes, mostly for aout right now

mmap changes, mostly for aout right now

[raeburn]

I've just checked in now some changes to bfd to use mmap for reading
files under certain circumstances.  A snapshot file should be available
within the next hour or so.  Please try it out and let me know of any
problems.

Currently the "certain circumstances" are limited to string and symbol
table reading for a.out formats, but the interfaces are available to
eventually be used by other formats as well.  There's some preliminary
code to support reading section contents via mmap, but it's not really
tested, and not used anywhere at the moment.  It's also not quite set up
right for optimal use by the linker; that'll take a little bit more work.

These changes add new interfaces for accessing file contents, where the
memory management is under the control of the BFD library rather than the
application.  This lets BFD determine whether mmap can be used or if
malloc/seek/read must be used, transparently to the application.

My tests on sun4 and linux(aout), using local disk, indicate some small
improvement using mmap compared with the old code, even though only
symbol and string tables are accessed this way.

Under NetBSD (on i386), I saw no significant change in CPU time used
(though my test case was different -- many more small files in and out of
libraries).  The linker does seem to work now, after a linker change I
checked in yesterday, based on some changes from Niklas Hallqvist; please
exercise that too.  The linker still takes about half again as much CPU
time as the system (pre-BFD) one, though the system one took more
wall-clock time in my tests than the BFD one, and the mmap changes
reduced the wall-clock time further still.  (I *think* the system was
otherwise idle, but there may have been some cron jobs running, so I
don't consider those last observations to necessarily be significant.)
The BFD linker can generate smaller `-g' executables than the pre-BFD one
due to the string table massaging it does.

Under Linux, using (a.out) object files read and stored over NFS, the
performance got worse using mmap.  My guess is that this is a Linux
problem.  I'm told the Linux NFS client code isn't particularly
spectacular, and I don't know what the mmap support is like.  Maybe some
use of madvise would help?

On host systems where mmap is not available, you'll get a slight
performance degradation compared with the older code.  But I think mmap
is likely to be available on most of the systems we care about these
days, so the tradeoff seems reasonable.

If mmap isn't available or doesn't work right on your system, and the
bfd/configure script doesn't detect that, please try to come up with a
test that does detect the problem.

There's still plenty of room for improving this code.  Using it in more
places, more efficient handling of mapping, perhaps mapping the entire
file in read-only, maybe using madvise, not modifying data in place after
it's mapped in, etc.

Like I said, let me know of any problems....

Ken

Re: mmap changes, mostly for aout right now

[Richard Stallman]

    On host systems where mmap is not available, you'll get a slight
    performance degradation compared with the older code.

I normally use a system which doesn't have mmap.
It seems to me that it ought to be easy to avoid any
performance loss on these systems
by simply using the old non-mmap code if mmap is not available.

Why not do this?

    Under Linux, using (a.out) object files read and stored over NFS, the
    performance got worse using mmap.  My guess is that this is a Linux
    problem.

This is a shame--it means this change actually does harm on today's
GNU systems.  We should not be making changes that help ONLY on non-GNU
systems and hurt GNU systems.

Can you please consult with Linux maintainers to see if this
is a bug in Linux that can be fixed straightforwardly?

If the slowness cannot be fixed soon in Linux, then please do
something in BFD to turn off use of mmap on Linux.  (This makes it
even more important to keep the performance of the non-mmap case as
good as it was before.)

Re: mmap changes, mostly for aout right now

[Ken Raeburn]

The file is never going to be written at the same time as mmap is
used, at least not in situations where I'd care about the results.
(If you're rewriting the input files while the linker is reading them,
you lose.)  But the file may get written by the assembler just before
it gets mapped by the linker.  Is it likely to lose in that case?  I'm
not very familiar with buffer-cache/VM interactions.

Autoconf already has one test for a known failure mode of mmap.  Can
you extend it to detect the NetBSD problems?  Would it only show up
with NFS?

I'm going to add some code so that the mmap code can be enabled or
disabled by configure options.  I want to get a release out soon, and
while the mmap code does seem to improve performance in most cases
I've tried, it's not worth risking serious instability.  It would be
nice to make it the default someday if I can get more performance out
of it, but that'll require more time and testing.

Re: mmap changes, mostly for aout right now

[Arne H. Juul]

 > I've just checked in now some changes to bfd to use mmap for reading
 > files under certain circumstances.  A snapshot file should be available
 > within the next hour or so.  Please try it out and let me know of any
 > problems.
[...]
 > Under NetBSD (on i386), I saw no significant change in CPU time used
 > (though my test case was different -- many more small files in and out of
 > libraries).
[...]

Unless I'm very mistaken, using mmap is currently a *very* bad idea
on NetBSD.  The buffer cache and VM system hasn't been merged, and this
leads to lots of trouble when using mmap(), at least on NFS-mounted
filesystems - the file as seen by read/write can be wildly different from
the mmap view.  This will (hopefully) change later on, but currently using
mmap() on NetBSD in other than very carefully controlled circumstances
will probably lead to disaster.

  -  Arne H. J.