[Bug 222356] www/firefox: file-backed shared memory performance

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sat Sep 16 16:44:43 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356

--- Comment #2 from Tijl Coosemans <tijl at FreeBSD.org> ---
(In reply to Konstantin Belousov from comment #1)
There are calls to msync and fsync in Firefox but they seem unrelated.  The
patch makes no difference (with Firefox patched to use MAP_NOSYNC but no other
changes).  At some point I also got strange build failures building Firefox so
I suspect the patch isn't safe.

Firefox wraps shared memory support in a C++ class.  The destructor unmaps the
memory and closes the descriptor.  The implementation isn't smart enough to
keep a pool or something.  I see a lot of disk activity (process in wdrain
state) when switching tabs, probably because some C++ objects related to the
now inactive tab are destroyed at that point.  And when all mappings are
removed and all descriptors are closed FreeBSD flushes pages to disk
(vm_object_terminate?).  When a file has zero links this flushing isn't needed.
 There's no point in writing data to disk that cannot be read again.  The file
is essentially extra swap space and pages should only be flushed to disk under
memory pressure, even without MAP_NOSYNC.

The following test program creates a data file on the first run and on the
second run it unlinks the file and uses mmap.  The second run shouldn't cause
any disk activity but it does on FreeBSD.


#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int
main(void) {
        struct stat stat;
        int fd;
        size_t sz;
        char *base;

        sz = 1024 * 4096;
        fd = open("nosync.data", O_RDWR | O_CREAT, 0600);
        fstat(fd, &stat);
        if(stat.st_size != sz) {
                ftruncate(fd, sz);
                base = malloc(sz);
                memset(base, '0', sz);
                write(fd, base, sz);
        } else {
                unlink("nosync.data");
                base = mmap(NULL, sz, PROT_READ | PROT_WRITE,
                            MAP_SHARED | MAP_NOSYNC, fd, 0);
                memset(base, (*base - '0' + 1) % 10 + '0', sz);
        }
        return(0);
}

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-gecko mailing list