Re: CVS commit: src/sys/fs/tmpfs

[Andrew Doran <ad%netbsd.org@localhost>]

On Sun, May 17, 2020 at 11:49:52PM +0000, maya%NetBSD.org@localhost wrote:

> On Sun, May 17, 2020 at 09:47:50PM +0000, maya%NetBSD.org@localhost 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