Date: Fri, 15 Sep 2017 19:21:54 +0000 From: bugzilla-noreply@freebsd.org To: gecko@FreeBSD.org Subject: maintainer-feedback requested: [Bug 222356] www/firefox: file-backed shared memory performance Message-ID: <bug-222356-21738-nw6P3XroFr@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
Tijl Coosemans <tijl@FreeBSD.org> has reassigned Bugzilla Automation <bugzilla@FreeBSD.org>'s request for maintainer-feedback to gecko@FreeBSD.org: Bug 222356: www/firefox: file-backed shared memory performance https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222356 --- Description --- Created attachment 186420 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=186420&action=edit firefox patch Multi-process firefox appears to use a lot of shared memory backed by files on /tmp. If /tmp is not tmpfs but a regular file system this causes significant delays. Scrolling pages can be slow for example. This can be improved by patching firefox to use MAP_NOSYNC which prevents dirty pages being flushed to disc as long as they are mapped. When they are unmapped (and all descriptors have been closed) FreeBSD still flushes them though and there are several situations where firefox does this (e.g. switching between tabs and minimising and restoring the browser window). The backing files have been unlinked so why doesn't FreeBSD just discard the pages? I've attached a patch for firefox that works around this problem by using POSIX shared memory with shm_open for the case of anonymous shared memory. Named shared memory is left unchanged but doesn't appear to be used. The patch also removes recording of the inode because I don't think it's valid for shm_open.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222356-21738-nw6P3XroFr>