Date: Sun, 17 Sep 2017 11:25:22 +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-QQmwGxgdlH@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 #3 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to Tijl Coosemans from comment #2) Which file system do you use ? The supposed mechanism is that when last on-disk link goes away, vp->v_vflag gets VV_NOSYNC bit set. Look for insta= nce at the ufs_remove(). Then, vm_object_page_clean() skips such vnodes, and t= his function is exactly what syncer calls to clean vnode' cached pages. How did you ensured that there is an io caused by the write-out of the data= ?=20 The metadata must be written on the unmap, and even unlinked vnode removal causes a lot of metadata writes on UFS. The inode must be prepared for reu= se by writing initial data, all inode data blocks must be marked as free in the cylinder group bitmask, the inode must be marked as free in another bitmask, then cg summary must be updated indicating new amount of free blocks and inodes. As a side note, I do not see how could my patch cause failures which you described. All it does is preventing msync(2) from actually write pages to disk for the unlinked file. --=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-QQmwGxgdlH>