Phil Harman <phil.har...@sun.com> wrote:
> I think Solaris (if you count SunOS 4.0, which was part of Solaris 1.0)
> was the first UNIX to get a working implementation of mmap(2) for files
> (if I recall correctly, BSD 4.3 had a manpage but no implementation for
> files). From that we got a whole lot of cool stuff, not least dynamic
> linking with ld.so (which has made it just about everywhere).
Well on BSD, you could mmap() devices but as a result from the fact that
there was no useful address space management, you had to first malloc()
the amount of space, forcing you to have the same amount of memory available
as swap. Later, the device was mapped on top of the allocated memory and
made the underlying spap space unacessible. We had to add expensive amounts of
swap that time in order to be able to mmap the 256 MB of RAM from our image
processor that time at Berthold AG.
> The Solaris implementation of mmap(2) is functionally correct, but the
> wait for a 64 bit address space rather moved the attention of
> performance tuning elsewhere. I must admit I was surprised to see so
> much code out there that still uses mmap(2) for general I/O (rather than
> just to support dynamic linking).
When the new memory management architecture was introduced with SunOS-4.0,
things became better although the now unified and partially anomized address
space made it hard to implement "limit memoryuse" (rlmit with RLIMIT_RSS).
I made a working implementation for SunOS-4.0 but this did not make it into
SunOS.
There are still related performance issues. If you e.g. store a CD/DVD/BluRay
image in /tmp that is bigger than the amount of RAM in the machine, you will
observe a buffer overflow while writing with cdrecord unless you use
driveropts=burnfree because pagin in is slow on tmpfs.
> Software engineering is always about prioritising resource. Nothing
> prioritises performance tuning attention quite like compelling
> competitive data. When Bart Smaalders and I wrote libMicro we generated
> a lot of very compelling data. I also coined the phrase "If Linux is
> faster, it's a Solaris bug". You will find quite a few (mostly fixed)
> bugs with the synopsis "linux is faster than solaris at ...".
Fortunately, Linux is slower with most tasks ;-)
In 1988, the effect of mmap() was much more visible than it is now. 20 years
ago, the CPU speed limited copy operations making pipes, copyout() and similar
slow. This changed with modern CPUs and for this reason, the demand for using
mmap() is lower than it has been 20 years ago.
> So, if mmap(2) playing nicely with ZFS is important to you, probably the
> best thing you can do to help that along is to provide data that will
> help build the business case for spending engineering resource on the issue.
I would be interested to see a open(2) flag that tells the system that I will
read a file that I opened exactly once in native oder. This could tell the
system to do read ahead and to later mark the pages as immediately reusable.
This would make star even faster than it is now.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
