Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Apr 2009 15:41:11 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org, Stephen McKay <mckay@freebsd.org>
Subject:   Re: svn commit: r190837 - in stable/7/sys: . contrib/pf dev/ath/ath_hal dev/cxgb kern
Message-ID:  <alpine.BSF.2.00.0904081527460.61921@fledge.watson.org>
In-Reply-To: <3bbf2fe10904080724i381c36fdpb1699def955fdb6d@mail.gmail.com>
References:  <200904080430.n384UGWw043589@svn.freebsd.org> <alpine.BSF.2.00.0904081500220.61921@fledge.watson.org> <3bbf2fe10904080724i381c36fdpb1699def955fdb6d@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Apr 2009, Attilio Rao wrote:

>> Finally, I think it would be a good idea to do a bit of real-world 
>> profiling on memory efficiency of the name cache: how much memory is wasted 
>> when assumptions about short/long are wrong, and could we retune lengths, 
>> limits, hash bucket counts, etc, to work better in practice?
>
> Am I wrong or you were working on adding DTrace tracing to it? Do you have 
> any interesting workload/numbers you can show?

While the probes I've added could be used to do this very easily, that's not 
the thrust of the work I'm currently doing.  A useful starting point for 
someone interested in this problem would be a dtrace script like the 
following:

vfs:namecache:enter:done
{

 	@distribution = quantize(strlen((string)arg1));
}

When run across a "du" of a portion of my local subversion tree, I get:

            value  ------------- Distribution ------------- count
                0 |                                         0
                1 |                                         2
                2 |@@                                       296
                4 |@@@@@@@@@@@                              1879
                8 |@@@@@@@@@@@@@@@@                         2719
               16 |@@@@@@@@@@@                              1974
               32 |                                         69
               64 |                                         2
              128 |                                         0

The result is that for my, quite toy, workload, large bucket entries are 
rarely used, and small entries make ineffective use of the space we've 
allocated because they rarely fill the full 32+ bytes we make available to 
small entries.  Other useful types of analysis might be:

- How effective is our LRU in the cache?
- What's the distribution of "times that entries spend in the cache"
- Is there a relationship between length and reuse of cache entries?

Doing these on real workloads is what's actually required, rather than on my 
running du on a directory tree.

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904081527460.61921>