From owner-freebsd-arch@FreeBSD.ORG Wed Apr 3 09:42:22 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7E0F294; Wed, 3 Apr 2013 09:42:22 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4E55DDA; Wed, 3 Apr 2013 09:42:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r339QKYd089859; Wed, 3 Apr 2013 13:26:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r339QKtq089858; Wed, 3 Apr 2013 13:26:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 3 Apr 2013 13:26:20 +0400 From: Gleb Smirnoff To: Pawel Jakub Dawidek Subject: Re: [CFR][CFT] counter(9): new API for faster and raceless counters Message-ID: <20130403092620.GT76816@glebius.int.ru> References: <20130401115128.GZ76816@FreeBSD.org> <20130402232606.GC1810@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130402232606.GC1810@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 09:42:22 -0000 Pawel, On Wed, Apr 03, 2013 at 01:26:07AM +0200, Pawel Jakub Dawidek wrote: P> > Together with Konstantin Belousov (kib@) we developed a new API that is P> > initially purposed for (but not limited to) collecting statistical P> > data in kernel. P> P> Is there any plan to implement universal way of exporting those P> statistics out of the kernel? P> P> Solaris has a framework for in-kernel statistics, which are exported via P> kstat tool. For ZFS I export them via sysctl. If you have ZFS loaded you P> can try 'sysctl kstat'. There are already primitives for sysctl in the branch: #include SYSCTL_COUNTER_U64(parent, nbr, name, access, ptr, val, descr); SYSCTL_ADD_COUNTER_U64(ctx, parent, nbr, name, access, ptr, descr); I do not think that every counter(9) in system should create an oid automatically. We are going to have counters per ipfw and per pf rule. P> It would be nice for counter_u64_alloc() to take additional argument P> 'name' and to create sysctl for the counter automatically. We could then P> slowly start migrating userland tools to use sysctls (or some wrapper P> userland API), but we immediately make those statistics available for P> use in scripts. Oh, in this bikeshed I am somewhere between your plan and the XML junta :) I'd better stay away from this discussion :) Let's keep topic on the new primitive. Just keep in mind that having a name would require another memory allocation, from normal not per-cpu malloc(9). P> > o Tiny API for counter(9): P> > P> > counter_u64_t P> > counter_u64_alloc(int wait); P> > P> > void P> > counter_u64_free(counter_u64_t cnt); P> > P> > void P> > counter_u64_add(counter_u64_t cnt, uint64_t inc); P> > P> > uint64_t P> > counter_u64_fetch(counter_u64_t cnt); P> P> Do you really expect other types in the future? If so, could we at least P> create generic counter_t that internally keeps the type? We will probably have signed 64-bit, actually allocated from the same zone. A type keeping type would require either additional allocation from malloc(9) or UMA directly, that would store the type, or we will store type in every per-cpu copy, wasting memory. -- Totus tuus, Glebius.