Date: Fri, 15 Sep 2017 19:21:54 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 222356] www/firefox: file-backed shared memory performance Message-ID: <bug-222356-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222356 Bug ID: 222356 Summary: www/firefox: file-backed shared memory performance Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: gecko@FreeBSD.org Reporter: tijl@FreeBSD.org CC: alc@FreeBSD.org, kib@FreeBSD.org Assignee: gecko@FreeBSD.org Flags: maintainer-feedback?(gecko@FreeBSD.org) Created attachment 186420 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D186420&action= =3Dedit 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 significa= nt 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 descripto= rs have been closed) FreeBSD still flushes them though and there are several situations where firefox does this (e.g. switching between tabs and minimis= ing 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 P= OSIX 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 a= lso removes recording of the inode because I don't think it's valid for shm_ope= n. --=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-13>