svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf

[Mateusz Guzik]

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>