On Sun, May 17, 2020 at 11:49:52PM +0000, m...@netbsd.org wrote: > On Sun, May 17, 2020 at 09:47:50PM +0000, m...@netbsd.org wrote: > > On Sun, May 17, 2020 at 07:39:15PM +0000, Andrew Doran wrote: > > > Module Name: src > > > Committed By: ad > > > Date: Sun May 17 19:39:15 UTC 2020 > > > > > > Modified Files: > > > src/sys/fs/tmpfs: tmpfs.h tmpfs_subr.c tmpfs_vnops.c > > > > > > Log Message: > > > PR kern/55268: tmpfs is slow > > > > > > tmpfs_getpages(): ...implement lazy update of atime/mtime. > > > > > > > I'm confused about how this makes sense. Can you elaborate? > > Presumably RAM is as fast as other RAM. > > riastradh responded to this elsewhere: avoid atomic ops
Right, also to: - avoid taking a mutex to serialize the update to the time fields in the tmpfs node. vnode locks are not held during getpages/putpages. the vmobjlock is held here and often read-held so there can be lots of concurrent access. - avoid doing a writeback on the tmpfs_node, which if it's heavily shared (consider for example ld.so or libc.so) involves lots of cache coherency overhead. - avoid querying the clock. Andrew