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

[jean-Yves Migeon <jym%NetBSD.org@localhost>]

On Fri, 23 Dec 2011 05:30:07 +0000 (UTC), David Holland wrote:
>  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.
> [snip]
>  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.

Came to the same conclusion this morning. Will check.

Merry christmas to all!

--
Jean-Yves Migeon
jym%NetBSD.org@localhost