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=222356 --- 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 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222356-21738-Hw6NF8aOVb>