Date: Thu, 4 Apr 2013 11:08:52 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Gary Palmer <gpalmer@freebsd.org> Cc: arch@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org> Subject: Re: [CFR][CFT] counter(9): new API for faster and raceless counters Message-ID: <20130404090851.GA1335@garage.freebsd.pl> In-Reply-To: <20130403002523.GA96431@in-addr.com> References: <20130401115128.GZ76816@FreeBSD.org> <20130402232606.GC1810@garage.freebsd.pl> <20130403002523.GA96431@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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! > > >=20 > > > Together with Konstantin Belousov (kib@) we developed a new API tha= t is > > > initially purposed for (but not limited to) collecting statistical > > > data in kernel. > >=20 > > Is there any plan to implement universal way of exporting those > > statistics out of the kernel? > >=20 > > 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'. > >=20 > > 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. >=20 > 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) >=20 > 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=20 > way. =20 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFdQyMACgkQForvXbEpPzQ7nQCffc5WCAP3N/0UcICJSbaCzbJr 9RsAnj7q9rmMP0G+useB/tzTvBQdExp8 =IExW -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130404090851.GA1335>