Re: kern/55268: tmpfs is slow

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

The following reply was made to PR kern/55268; it has been noted by GNATS.

From: Alexander Nasonov <alnsn%yandex.ru@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: kern/55268: tmpfs is slow
Date: Fri, 15 May 2020 18:14:51 +0100

 Joerg Sonnenberger wrote:
 > The following reply was made to PR kern/55268; it has been noted by GNATS.
 > 
 > From: Joerg Sonnenberger <joerg%bec.de@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: kern/55268: tmpfs is slow
 > Date: Fri, 15 May 2020 18:29:47 +0200
 > 
 >  On Fri, May 15, 2020 at 03:55:00PM +0000, Andreas Gustafsson wrote:
 >  > Doing a "build.sh -j 24 release" on a tmpfs takes more real time than
 >  > on an ffs mounted with "-o async", and uses much more system time.
 >  
 >  Careful with DIAGNOSTIC as it increases vnode lock contention quite a
 >  bit. Don't have the performance numbers for the bulk build anymore, but
 >  it is quite visible. Otherwise, this greatly suggests some form of lock
 >  contention or another, so lockstat output would be the most useful thing
 >  (e.g. lockstat -b 999999 build.sh ...). This doesn't reflect my
 >  experience at the very least, but lock contention can be somewhat
 >  catastrophic and small changes can have dramatic impact. That said, in
 >  the current form the bug report is not really useful.
 
 Andreas stated that DIAGNOSTIC and acpicpu are DISABLED.
 
 This is very similar to my setup but I run on AMD EPYC. When I was
 measuring build performance on tmpfs, I often ran lockstat and I
 sent some of those reports to ad@ for analysis. He may have some
 ideas what's going on there.
 
 -- 
 Alex