[CFR][CFT] counter(9): new API for faster and raceless counters
Pawel Jakub Dawidek
pjd at FreeBSD.org
Thu Apr 4 09:06:55 UTC 2013
On Tue, Apr 02, 2013 at 08:25:23PM -0400, Gary Palmer wrote:
> On Wed, Apr 03, 2013 at 01:26:07AM +0200, Pawel Jakub Dawidek wrote:
> > On Mon, Apr 01, 2013 at 03:51:28PM +0400, Gleb Smirnoff wrote:
> > > Hi!
> > >
> > > Together with Konstantin Belousov (kib@) we developed a new API that is
> > > initially purposed for (but not limited to) collecting statistical
> > > data in kernel.
> > Is there any plan to implement universal way of exporting those
> > statistics out of the kernel?
> > Solaris has a framework for in-kernel statistics, which are exported via
> > kstat tool. For ZFS I export them via sysctl. If you have ZFS loaded you
> > can try 'sysctl kstat'.
> > It would be nice for counter_u64_alloc() to take additional argument
> > 'name' and to create sysctl for the counter automatically. We could then
> > slowly start migrating userland tools to use sysctls (or some wrapper
> > userland API), but we immediately make those statistics available for
> > use in scripts.
> Sorry for potentially turning this into a bikeshed, but is sysctl the
> best interface for this? It is great for scripts as the CLI is already
> there, however it is not a bulk interface so grabbing all the ZFS
> statistics takes quite a few trips through our system call handler - 438
> on my 9.1 box for "sysctl kstat" (found via ktrace and then
> kdump | grep -c SCTL), which is not ideal when there are only 87
> stats there. (5 calls per OID returned and 3 initial calls to get set up)
> I'm not sure I have a better alternative other than a geom style bulk
> export via XML or some other format, however I wanted to raise it for
> consideration. I wouldn't hold up the checkin of the code for this,
> however if another way of gathering the data is needed/desired then it
> would be good to get it in before people get too used to the sysctl
XML is no go for me, as it is not really easy to use in scripts.
We would need to create a tool to parse it and then I'd much prefer to
import my API for dealing with name/value pairs that could be used in so
many more places.
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the freebsd-arch