Date: Thu, 2 Apr 2015 17:38:05 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ian Lepore <ian@freebsd.org> Subject: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf Message-ID: <20150402153805.GD549@dft-labs.eu> In-Reply-To: <20150402143420.GI64665@FreeBSD.org> References: <201504012226.t31MQedN044443@svn.freebsd.org> <1427929676.82583.103.camel@freebsd.org> <20150402123522.GC64665@FreeBSD.org> <20150402133751.GA549@dft-labs.eu> <20150402134217.GG64665@FreeBSD.org> <20150402135157.GB549@dft-labs.eu> <1427983109.82583.115.camel@freebsd.org> <20150402142318.GC549@dft-labs.eu> <20150402143420.GI64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 02, 2015 at 05:34:20PM +0300, Gleb Smirnoff wrote: > On Thu, Apr 02, 2015 at 04:23:18PM +0200, Mateusz Guzik wrote: > M> Well, a thread migrating to another cpu is the standard thing everyone > M> sees. > > How often do you see it right in a particular window of 2 or > 3 instructions? > > If you carefully read the thread I referred to, you would notice that > on many arches, save amd64 and i386, all systems stats are prone > to mangling the stats due to migration within PCPU_INC. Look here: > > grep '^#define PCPU_ADD' sys/*/include/pcpu.h > > Do we have reports on not precise enough statistics, yet? How many non-x86 installations with multiple cpus and high traffic are out there? Also note that stats should be roughly equally distributed amongst CPUs which do the work, so an occasional mismatch is likely to go unnoticed. Would be nice to get this fixed at some point though. > > M> I don't feel that strongly about changing the code. If it stays as it > M> is, it definitely needs the comment I mentioned explaining why migration > M> is fine. > > I just added the comment. > Thanks! > M> If the code was to be changed a machdep counter_u64_fetchadd seems like > M> the only course of action. > > If we have more places in kernel, where such API is required, I would do > it. Alas, seems like not possible to make it without critical section, > even on amd64. Note that counter_u64_add() on amd64 is critical-less. > Yeah, but that should be cheap. Worst case on amd64 it could be microoptimised with removal of func call and inline critnest manipulation with compiler barrier. Afair Ian said that on arm they could hack around it nicer with atomics, don't remember atm what's the holdup (if any). tl;dr this should be doable without technical problems and does not have to affect counter_u64_add. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150402153805.GD549>