Re: kern/45734: performance regression for sequential/random creation of files, as well as stat(2) (ffs fs)

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/45734: performance regression for sequential/random
 creation of files, as well as stat(2) (ffs fs)
Date: Fri, 23 Dec 2011 05:27:56 +0000

 On Thu, Dec 22, 2011 at 11:30:00PM +0000, jym%NetBSD.org@localhost wrote:
  > I narrowed the regression to this window:
  > 
  > GENERIC 2011-07-03
  > seq_create ran_create ran_stat (#/s)
  > 4374 4499 6052
  > 4488 4553 6008
  > 4616 4574 6057
  > GENERIC 2011-07-05
  > seq_create ran_create ran_stat (#/s)
  > 1518 1539 1698
  > 1534 1521 1689
  > 1532 1541 1713
 
 On July 3 DIAGNOSTIC was turned on by default. Can you (1) check if
 that's really one of the differences between your two endpoints, and
 (2) if so turn it off in the July 5 kernel and see what the
 performance looks like?
 
 DIAGNOSTIC is not supposed to be expensive but that isn't necessarily
 working right.
 
 The only fs-related commits I see in the period are manu@'s extattr
 cleanup, and that isn't really very credible as a source of
 performance problems.
 
 This is the only other even remotely likely candidate I can find:
 
    ------
 Module Name:    src
 Committed By:   yamt
 Date:           Tue Jul  5 14:03:07 UTC 2011
    
 Modified Files:
         src/sys/uvm: uvm_km.c uvm_map.c
    
 Log Message:
 - fix a use-after-free bug in uvm_km_free.
   (after uvm_km_pgremove frees pages, the following pmap_remove touches them.)
 - acquire the object lock for operations on pmap_kernel as it can actually be
   raced with P->V operations.  eg. pagedaemon.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.109 -r1.110 src/sys/uvm/uvm_km.c
 cvs rdiff -u -r1.299 -r1.300 src/sys/uvm/uvm_map.c
    ------
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost