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

2020-05-19 Thread Andrew Doran
On Tue, May 19, 2020 at 11:09:07PM +, Andrew Doran wrote:

> vnode locks are not held during getpages/putpages.

^ for fault handling, anyway.  for read/write they are held by the caller to
ubc_uiomove().

Andrew


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

2020-05-19 Thread Andrew Doran
On Sun, May 17, 2020 at 11:49:52PM +, m...@netbsd.org wrote:

> On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> > On Sun, May 17, 2020 at 07:39:15PM +, 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