Date: Sat, 16 Sep 2017 16:44:42 +0000 From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: [Bug 222356] www/firefox: file-backed shared memory performance Message-ID: <bug-222356-21738-Hw6NF8aOVb@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-222356-21738@https.bugs.freebsd.org/bugzilla/> References: <bug-222356-21738@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222356 --- Comment #2 from Tijl Coosemans <tijl@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 ot= her 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 nee= ded. There's no point in writing data to disk that cannot be read again. The f= ile is essentially extra swap space and pages should only be flushed to disk un= der 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 cau= se 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 =3D 1024 * 4096; fd =3D open("nosync.data", O_RDWR | O_CREAT, 0600); fstat(fd, &stat); if(stat.st_size !=3D sz) { ftruncate(fd, sz); base =3D malloc(sz); memset(base, '0', sz); write(fd, base, sz); } else { unlink("nosync.data"); base =3D mmap(NULL, sz, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NOSYNC, fd, 0); memset(base, (*base - '0' + 1) % 10 + '0', sz); } return(0); } --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222356-21738-Hw6NF8aOVb>